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Abstract 

Abstract data types are the basis of an emerging methodology of computer programming. The 
only existing languages supporting pbslap*^^ 

compacting garbage collection, and thus they are not suitable for many applications. This 
thesis presents the design of a new language incorporating abstract data types; the language 
requires only a run-timeatack, and not garbage collection. This mw language, called ASBAL 
(for "A Stack Based Abstraction Language"), is based »n!lSLU,s«iid bonowaaa many features 
as possible directly from it. Virtually every significant feature of GLU is carried over into 
ASBAL in some form, and extensions are tattooed «hen necessary. For example, the 
maximum size of objects becomes an issue and is resolved by the addition of size parameters to 
types. Also, a* limited faclftty for dynaimlc storage^ «° 

compensate for the removal of a garbage collected heap. This facility allows list and graph 
structures to be built uithin the f ranieiwk of tue ftaifc^ 
as a *side-*eff ect" of compHe^tinw type checking. 
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1. Introduction 

In recent years the correctness of computer programs has become a topic of growing 
interest. One approach taken to enhancing correctness Is the forrnulatioh of design and 
programming methodologies. It is 'hoped 'rt^^e^iyii».il^Wl^teved by usifig appropriate 
structure and discipline in the programming pnii^^fi#f^if'^ii^^<toa''ly^ Is one of 
the techniques being developed. Abstract data types appear promising for simplifying proofs 
of program correctness, and seem to be naWaf ;: f or ' pet^lf*!© 4 Use in programming and in 
communicating among themselves about programs. 

I.I. Motivation 

To date only two programming languages have ; been i implemented .-.that, provide and 
enforce the abstract data type discipline directly in the language: CLU [LUkpvTTJ, and 
extensions to Simula [Dahl66J. However, both languages require compacting garbage 
collection. The main difficulty with garbage collection is the "embarrassing pause" which 
occurs whenever the garbage collector is invoked. Such a pause is intolerable tot realtime 
systems such as operating systems, process control programs, etc One way to eliminate the 
pause is to use parallel tSteelelSal or irJci^eMiWbiT t1^di^77; ' B^i«iiscfi76^ "Baftfi77J garbage 
collection techniques. These methods 'havlr : ti§ ^etfect' of'l^rlaaWg the pause out uniformly 
over the normal processing time. Unfortunalely, efficient parallel garbage collection probably 
requires special hardware, and k therefore not suitable foremost applications, especially those 
relying on existing hardware. Incremental garbage collection appears to be more promising, 
but both parallel and incremental techniques for objects of different sizes (we say variable size 
objects) copy from one object space to another. Each space Is one half of the total free memory; 
thus the maximum amount of memory usable with the parallel or incremental techniques is half 
of the actual memory provided. This severely restrtorTlar * applications possible on most 
machines, particularly mini- and rnkro-computers, which, have ,imaU address spaces to begin 



1. We assume the reader is familiar with abstract data types. For those lest well versed? if* the 
recent literature the following papers may be helpful: tLtskov77, Wulf76a, Liskov75, Guttag75I 
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with. Another drawback, to garbage cohectton is that the memory manag ement system might be 
a ..prime candidate for using abstract datatype!. Oaaiiy the farawge caMecMr tt part of the 
memory management, system. If the b*uj?MW which AiaaM «wA^PMh4Miwt data types 
requires garbage cobection, then thai: tajguagc cinnot be used io write the garbage collector. 1 
One might hope that a useful subset of the fr aguage fhsr i oews i w* roBOtee garb e ge coMection 
could be used to write the garbage collector . Howe*er there H wo aach whf i», at either QU) or 
^imula: they depeiKl ongart>H« <»U<«i» ««Uf«»l- 

We feel that thft «/#»#* sohftten to the garbage cetetaTn pxpbJam is buUcUng parallel 
garbage collection into computer hardware, ,_, to the costofhacdwaw conth*ues-|^ drop, and the 
cost of of software pr e domi nates, it may pay *o doable the reeanory .reejuired to have parallel or 
incremental garbage collection, and thus maa* available i hwjiu and puw*i rot pr ogr a mming 
languages that ease software development. However, m the inlwhu, and f or apphcattons where 
the added hardware cost cannot be >isttf led w- address apa«eto\at a ptemium, we feei another 
solution is in order. In this thesis we present a new programiiung language incorporating 
abstract data types In a manner that (hmr^retpiimgirbagn ciMicrieii 

1.2. The Goal 

We have designed a new language wjth abstract-data types that will run with only a 
run-time stack. This stack is similar to those used by other high hwri latiguagea such as Algol, 
Pascal, and PL/1. 2 Rather than designing this rtew au«mge.f4>em scra^,^ have uted CLU 
as a basis and have concemraled on reie*^ 

understand what we have done -jFjhjBUL rey ti« a gasp tf why f*rba^ in 

CLU. 



1. Without special tricks, that is. We feci that tricks of this sort should be avoided and an 
e«egant- solution found that does ik« mvoWes tHcks c^ aptcMI casea^ 

2. For some applications static allocation might be a ppr op r i at e , we did not investigate that 
approach. However, see the suggestions for further research kn the last chapter for more 
comm ents about ft. • ■■■■■>>■.»,<- ■• ,•■<-. ■•■ <*. 
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1.3. CLU and Garbage Collection 

j 

The coincidence of several parts of the semantics of CLU makes garbage collection a 
necessity. The basic unit of information in CLU Is an object. Every object has a type, and may 
be manipulated only by the operations of Hs type: this is the key to abstract data types. 
Conceptually, objects exist independently <o£ programst and once created are never destroyed. A 
variable is simply a reference to an object, that Js, a name for H* It is important to realize that 
variables do not contain objects, bug<raftj^o^^ by pointers or 

capabilities. Two variables may refer to the Jpw* object - we say they short that object. 
Objects may refer to other objects, so objects can be shared by objects a* well as by variables. 
This is useful in building hitrarchtcal, graph, and Hit data structures. Furthermore, cyclic data 
structures can be built, thus implying that ref^tnee counting will not auffke to reclaim all 
unused storage. Because varfabia ttiaobjectt a« u*ed, conia»cting garbage collect km is needed 
to prevent fragmentation of sto/age, ■ :*■•. > r . 

In CLU, alignment, argument passing* and the tejsjrn of results are all accomplished 
by transmitting object referencesi^ne objects«ar««£6e£tedL Fori«x*mpte. in 

x:-y; 
the variable x is made to refer to the same object as that referred to by y. The object referred 
to by y is not affected in any way. In the case of argument passing a similar thing happens. 
The called routine is given references to the arguments being jHUsed to, it This is not the same 
as call by reference: the called routine does not have access to the variables of its caller. 
However, the objects passed are shared between the caller and the called procedure. Therefore 
any modifications to the objects will be visible to the caller. 

Any procedure can create new objects at will, and these objects are stored in the heap. 1 
References to objects can be stored in other objects and also returned to the caller directly. We 
will call the object semantics of CLU the object-orltnttd approach. 

In sum, CLU objects must be allocated in a heap because (a) they can be of 
unpredictable size, (b) their size can grow over time without bound, and <c> their lifetime is 



1. A heap is a global, garbage collected storage area, like that of A%ol 68 tWijngaarden77]. 
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indefinite. Garbage collection is requited beauite qpeke ttracturn can be built. Compacting 
garbage collection mutt be used to prevent f r agmtntaUon of mtmory, because variable size 
objects are used. ■.'•-..'-,'.' .-.'> -.(.-.■- -,/~ • 

1.4. Our Approach 

CLUV major centrtbution is the -abstract data tvpe f aertty, not the objed-ortented 
view. It appears that the ob ject-^riemed vte^ it ^>souree eT 'rbe lequaVm entf or garbage 
collection, as oueltffi*»al»oiMV"M the 

object-oriented vie*. As wilt beexytairted't ff im ea de sail irl ^is^ ^thr semantics we arrive 
at is a synthesis of the tratiltiemt use of ^ai ^ abtu aw»^^JV use of objeto. Snaring of 
objects is eHmhwied, arid (to UfetJme-of efcjtttt 4»^ bf storing 

objects in, n niubhi niiOiii aiMiaaMiie lieMiSjiS^wl ftfiiiialiisillllg thl wasiirt Wlwiti >ai)ilih i - 
'may :- be man ipo fatted. Qui i piSSMiH -b*»-*QpmM*M IHlJ 11 MJpMl Bftaiilid view-as ctosety as . 
possible. We xall our rcsulUiigderign 'AStadt-Baaed Abtt i lia^ to it a* 

A&a*fc . We*h*mmm, iimfiarisir hi ifiiip an isiiiw lwajssstriM ilnwi. Inn Ins 

concentrated- ' on the nan s nilu. TlW l yn S M t-a ^^^ be. 

'~r " A " ' 1 1 luririn lan|tiap Inn tiny ier i ■ m nail H i sii m Iim i ii 

1.5. Related Work 

The goals of trie Alphard I tanguagedesign group [W«tf^l appear to be very similar 
to ours: Alphard has abstract data types and rum with only a stack. However, Alphard is still 

under development and It is not clear how similar Atphatd and ASBAL reaHy are. We suspect 

ut'«j- -A- w "k'u^y-.isv «lw ?.^*sioG arts 0- ^'f.*a*«l«,'--j. ; v '■;•<•■ .-'*"-. 
there will be significant differences because of -our/ adherence to a more object-oriented 

approach. Furthermore, Alphard seems to conce ntrat e more on provabilfty (see [Wulf76a, 

Wulf76b. Wulf76c])' 

The language Euclid [Lampson77] is also somewhat refcsted to our work. We are 

especially indebted to Euclid for the concepts of abasing preven ti on and collections. Like 

Alphard, Euclid is not object-oriented. Furthermore, Etocttd was not specif scatty designed to 

provide abstract data types, although they can be mo a all sd in Euchd to a g rea t e x ten t. Euclid 
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places more emphasis on provability than we do, and on systems implementation features. 
Euclid is a more complete language than ASBAL, but our intention was not to design a 
complete ready-to-use language. 

The language Simula is also somewhat related to ASBAL. Simula could be described 
as CLU's ancestor, and CLU is ASBAL's ancestor, so the relationship i% one of progressive 
development. No specific feature was consciously taken directly from Simula in the design of 
ASBAL, but much was taken from CLU. 

The language most closely related to ASBAL is of course CLU, since it was the 
starting point of our design. 

1.6. Outline 

This introductory chapter is followed by five chapters. Chapter 2 introduces the basic 
semantics of ASBAL, laying the philosophical and semantic foundations for the rest of the 
design. The third chapter extends the basic features with two mechanisms taken from CLU: 
iterators and exception handling. Chapter 4 further extends ASBAL by adding parameters to 
abstractions. The parameter mechanism of CLU is copied, but a significant new feature is 
added - size parameters. The fifth chapter investigates a topic foreign to CLU: dynamic 
allocation of objects without requiring garbage collection. In Chapter 6 we summarize our 
research, draw conclusions, and make suggestions on how our work can be extended, 
mentioning other approaches to our problem deserving investigation. 

There are two appendices, which more completely define our ASBAL. The first 
appendix gives a context-free grammar with explanations of the various productions. The 
second appendix outlines the basic data types and their operations. 
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,2. Ba?fto Oossocrpts 

This chapter presents many fundamental Ideas of ASBAL. We begin with a 
discussion of the philosophy behind objects and vaifeblfi in prpframming languages, point out 
particular aspects of this philosophy that directly impact our decisions in the design of ASBAL. 
and arrive at the basic semantics of variables for ASBAL. From this we develop the semantics 
of procedure invocation, assignment, and setoetioo of components of objects. After a discussion 
of implementation techniques, we present an example type detoitton to illustrate the material 
introduced. 

2.1. Philosophy of Objects and Variables 

Variables in traditional programming languages serve two major functions: they 
provide a naming capability, and they provide c o ma i mi'i for info r matio n (fee., storage space). 
CLU, with its object-oriented ^riew, separates these functions. ^Objeets : are the information 
containers of CLU. CLU variables hold only Hie names of Objects. (We generally say the 

:■...... .'..,'.' ; , ■...»,.. » 1 ., j.,>t- ., ;...,:.■-,.;',:, A 5i».-.i. ..,,.. ..,,,.- t . J. .J ij ..-- .-■• .. . i ...... 

variable denoUs or r«jflrrj fo the object) Objects have an indefinite lifetime, and may be 
referred to by many variables at once. Hence, Objects arelmirt e mented ass storage allocated in a 
heap, with variables being pointm to the ^ other 

objects, and general graph stnicturei of *jecttaTe allowed. 

Some objects have time-varying property The state 

of a mutable object iN the set of properties K has at ^eme poihr tn ^Hme); For example, the 
Abstract tyjpe staek isTmitabte The state of a stack u the c*ttered seooenee of objects in it. A 
push or a pop muter** a stack, Ms., gives it anew stttte. On n ^e- o th er hand, a test for emptiness 
will not change the state of a stack. 

Imrntadbtt objects are those whose properties do not vary over time. Most 
mathematical values are immutable, as are their computer language models. (The values not 
the variables in which they are stored!) For example, integers, real numbers, characters, strings, 
and boolean values are aM immutable. The integer T is an Immutable object. "2? is *2* no 
matter how you slice it, and "2*. can never be changed to any other integer 

The separation of the naming and storage functions of variables achieved by the 
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object-oriented view leads to a clean semantics. But probably the most Important reason CLU s 
object-oriented semantics is attractive is thlit people seem to think in terms of objects, The 
very structure of language, with nouns (naming objects), adjectives (describing the properties 
of objects), and verbs (describing the use of objects or their behavior) seems based on this view 
of the world. If it is indeed true that people think in terms of objects, then linguistic forms 
that enable people to program directly in terrru of objects could lead to better software design 

and implementation by being more natural for people to use 

.. ' -„ . - -^ , . M.if. -.-{if 1 - ' < 

Of' course, the kind of objects to be found in programming concepts are highly 

abstract often mathematical in nature. So, there remains much structure to be built to model 

real world objects and systems. This Jack of structure allows the freedom necessary in a 

general-purpose language. For domain specific systems (eg., medical diagnosis), more structure 

may be desirable because it embodies useful assumptions and prevents "reinventing the wheel 

for every specific task. However, ASBAL is to be general-purpose. The abstract data type 

facilities allow one to build specialized systems by accumulating a library of type definitions 

and procedures relevant to the application. OuV modeling of objects must extend to abstract 

data types to be useful. For this reason ASBAL is designed from a very general point of view 

with respect to types, This may make our descriptions of semantic concepts seem very vague. 

It is hoped that the many small examples we give will help offset the abstract descriptions. 

2.2. Variables in ASBAL 

As was discussed in the first chapter, our baajg cons#aJM in the design of ASBAL is to 
obviate the need for garbage collection. TrUs, we aig^ued, irapAiei ekher static- or 
stack-allocation ..o| ! ^oragf. We explained that our investigation i* restricted to «ack allocation 
CLU-style objects cannot be stack-allocated in atty,jea*enable way, because they are very 
general structures. We have decided that the belt approach for ASBAL is to^tore objects in 
variables similar to traditional variables. The sirnrdici^jjf fhe method directed our choice. All 
other mechanisms we considered were intrteate aiKl t^mptee. Storing objects in variables is not 
as nice as the f utt-blown bb ject-oriented approach of CLU but; it appears to be the best we 
can do. The assignment, procedure .call, anoVcompoBeat selection mechanisms were designed 
very carefully to help offset the limitations imposed by working in a stack. Here is a summary 
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of the object interpretation. 

A variable contains an object. An object lots a type, and so does a variable: a variable 
may only contain an object whose type is the same as to own. Assignment Witt be used only to 
change which object is stored in a variable. An assignment effectively destroys whatever object 
previously existed in a variable, and creates a new object in its jrface. To change the state of 

'■■■>;'■ -' ...V. ' .■"*■■'■ "■ ■• '■'.: y .::•>'! c? '-f?r"' ! .'*1 i>:<"' i !7*li ?i ! ? ; SiK* 

an object, the object must be passed <ustng the procedure invocation mechanism) to an 
operation of its type. 1 An operation that changes an object's state if sa|d to mutat* the object. 2 

We emphasize that assigning to a variable ^ not the same as mutattng the object it 
contains. This is because mutable object* may have pr op ert ies defined by their, creation which 
may never be changed later. For example, consider an, abstraction , ear that models automobiles. 
At creation the make, model, and serial number aw specified; these properties of a car may 
never be changed after it is created. On the other hand, the number of passengers in a car 
and location of a car can change ouHe frequently. Although all the prooerties of a car are part 
of its state, only some of these properties can be changed by mutatton. However, if a car 
variable is assigned a new car, oft the properties might be difterent from those of the previous 
car. 

Objects may have other objects as components. Components of an object are stored 
within it, and hence within the variable containing it. This is quite different from CLU. 
where only references to components are stored m an object. 

Several consequences of this object interpretation of varieties should *e mentioned In 
CLU, assignment Is system-defined: it is an implicit op e r ation . This is because a CLU 
ali gnm e nt entaffs only copying an object ref erence/ranNer luie oapymg a pointer or capability. 
On the bother 4hnH *we must construct an entire object m each auig n rn en t ; this new object 
repteces the one previoush/Testdrng in the assigned variable. T he tun^eqa e nim of this fact will 
be explored 4iv the seetnwow^fcfiiiiiem. . - l ; Wh ' 



1. Recall that the abstract data type metho«iolO|y altowj only the operations of a type to access 
or update the representatic«i of objecu of that type. 

is accomplished by mutation of records or array*. Muttijtton is ^ a ; sense raagicaJ, since the 
mutating operations are atomic. That is, the furidamental mutating operations cannot be 
broken down into other, inore^ba^ .. .,•& ■■■■■ 
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Another consequence of the object interpretation is that sharing of components is 
disallowed, because components are directly contained in their *parent" objects, rather than 
being referred to (pointed to) as in CLU. For example, in CLU two elements of the iame array 
may be the same exact object, and any modification to this shared component object via one 
access path will be visible via the other access path. Our objects cannot share components in 
this way. (The addition of pointers to ASBAL rettores the ability to share, so we are not 
giving sharing up completely.) 

A rather obvious result of our semantics is that the lifetime of an object is bounded by 
the lifetime of the variable containing it, rather than bein^ ^unbounded as iff CLU. The major 
implication of this is that ASBAL routines will not be able to return objects in the sense that 
CLU procedures do. In CLU, procedures return references to objects; hence, previously existing 
objects may be returned by just copying refeirnces to thwi. In ASBAL we are restricted to 
constructing new objects to be returned. ' 

The binding of an object's lifetime to that of its containing variable, along with the 
storing of components within objects rather than sj^rj|e|f| ,^0^-^-p^^M^^^.^^ 
selecting components. In CLU, components can be selected by just returning them since only a 
reference is returned. On the other hand, our returns always create new c*jec», so returning a 
component cannot be done in the same sense as in CLU: we can only construct a copy of the 
component Therefore, without a hew mechanism, component objects may never be motated, 
although new component objects may be substituted by operations on the containing object. 
Since we should be able to do anything with component objects that we can do with entire 
objects, a ne^w mechanism is required to allow mutation of components. A hew kind of module, 
the selector, is introduced for this purpose; it will be described in a later section of this chapter. 

A last consequence of our semantic model is that objects cannot grow dynamically, at 
least not without bound, because they are restricted to the storage allocated for the variable 
containing them. This leads to difficulties when trying to implement abstractions that are 
conceptually unbounded. The parameter and area mechanisms to be presented later are largely 
devoted to solving this problem. 

To sum up, variables in ASBAL are containers for objects. Objects have a type, 
which indicates how they may be manipulated, i.e., what operations are allowed on them. 
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Variables are also given a type; indteatmr what type of objects they may contain. Variables 
will be implemented as storage aikxated in a stack; the objKt Marpretatioii we espouse only 
puts limitations on how that storage may be nwttputoted. The im£r difference* between our 
objects and heap allocated objects are 

* <fl our objettr are stored* wwhtn vartabfes, so assignment it different - the old object: in 
the variable autgned lb is destroyed and a new objkr created in the oht one's place; 
(2) because objects are stored in variables, an asstgnnwrt always involves creating an 

"object; ' ■ ' . 
(?) there can be no sharing of objects anwtig variables, or components of objects among 
objects and variables; 

(4) the ttfetlmeof an object is bounded byrtHe lifetime of the variabhr containing it, 

(5) and, the st» Of arncfcjsttfs bounded by ^ 




The next few sections of tWs chapter explore the connjqusnm of these differences in more 
detail, and present ASBALTmechjmlfc mt for the i 

2.2.1. Declaration* and Name* 

Programs must be able to refer to- objects in order to nwmipuhvte thorn. Hence, (some) 
variables- in ASBAL will be given namt*;to ; g^ 
to distinguish them from name* used for other purpe^ s^ 
It »» generally cotTvenient to create a new varu^ of some type an^^ 
time In AS BAL a dectaratton statement such at 

vmrx: foe- 
is used to do this. In the example, a new varirtte of type/be is created and gtven the name x 
A newh> created variable? as constructed by a declaration, contains no object; m I* an error to 
attempt to use it. (We have more to say about mitiataatton of varta*rte^bekw.) One can easily 
extend the form of the declaration statement to aHow dedt^atlem of several vartabtes at once. 
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var x: int, y: bool; 
or 

var x,y: int; 

2.2.2. Variable Initialization 

We define our declarations to cteate^ew vaf iabtes. £ha* is, ones never before known or 
used. This definition prevents confusion over whether a "new" variable contains an old object. 
It does raise two problems, however. The first is that memory allocation is required - this is 
discussed in the section on implementation later in this drtpter. The second problem is that the 
bits initially in the storage allocated for the variable may not represent a legal object of the 
type of the Variable. There are two solutions to this problem. One is to store a default object 
of the declared type in the variable as part of the actions taken for the declaration. This can 
be done for user defined types as well as system-provided ones by requiring each type 
definition to have a routine of a particular name ttnff, say) which will store an initial object in 
a variable given to it by the system. This solution guarantees that variables always contain 
legal objects (assuming users do not write crazy init routines!). But unfortunately, it cannot 
guarantee that the objects are sensible, since sensibility depends on how a variable is used. 

The better solution is to consider attempts to use an uninitialized variable as illegal, 
and to detect such attempts with a combination of compile-time and run-time checks. Exactly 
what checks are required is discussed in the section on implementation later tn this chapter. 

2.2.3. Constants 

It is sometimes convenient to have a bolder for an object that cannot be assigned to 
after initialization, and that does not allow tb* object to be ^nodif ted. We call such holders 
constants to contrast them with varjables; they are sim^ to constant objects in CLU 
However, we allow constants of mutable types, such as constant arrays. Since a constant 
physically contains the object stored in it, modifications can easily be prevented by disallowing 
any write operations to the storage allocated to a constant We will see later that wf otn pass a 
variable to a procedure but have the procedure consider it to b< a constant. This is the real 
motivation for constants - prevention of undesired modification to objects. 
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A constant definition is simitar to a variable declaration, except that the object to be 

stored in the constant nw$t be specified. Thus, in a constant definition wv§h» the desired 

name, type, and the object to be stored in the constant: 

const n: in* » 53; 

const i: int - j * k; 

const a: arrayf int> - arraj$crea«etO); 

In an implementation there is Wtm difference between a constant and a variaWe. a constant is 
essentially a wrlte-ortce variable. 

2.2.4. Scope and the Form of ASBAL Modules 

To gain an understanding of the scope of variable and constant names, we must 
consider the general form of module* m A8BAL. The two basic modules of AS BAL are the 
cluster, which implements a data abstraction, and the ft rw dui^ which imple ments a procedural 
abstraction. 

A cluster defines a data abstraction, by giving a representation (of ten shortened to rep> 
for the abstraction being defined, and tmokroentatiom ctf trw operations. The operation 
implementations take the form of procedures, but have the added abmty to convert objects of 
the abstract type to and from the rep type. Internal operations may be used; the cluster lists 
which of the operations may be used outside the cluster. 

A procedure has a header and a body, the body being a list of statements. The header 
gives the types, and names of the arguments, the types of any results returned, and other 
information to be described later. 

Each abstraction is implemented in terms of lower kveV abstractions. The overall 
structure is a hterarcht<^ decomposition, with the highest level ibstracttoni at the top, and the 
lowest level abstractions being types sn& procedures built into rhr language A module is an 
imphjmentaften of an abstraction. 1 Because an abstracthm is entire onto itself , a free standing 



1 A module may implement z class of related abstractions, rather than a single abstraction (see 
the chapter on parameters*. 
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mathematical object, modules are conceptually separate ami independent' For example, there 
are no free variables in ASBAL modules, because this would represent a dependence on 
another module to supply those variables. 

This model is somewhat contrary to the more common block-structured view of 
programs in at least two ways. First, the block-structured I view leads -jo large monolithic 
programs, and the whote goal of modularity is to prevent such huge programs. Second, we 
allow only local variables, not global variables. This supports modularity by making module 
relationships more explicit: any data that a module wishes to access must be passed as 
arguments to that module. Since each procedure defines a distinct abstraction, and every 
abstraction is implemented by distinct modules, nothing is g»»ntd by deflB4l« 'procedures 
within procedures. In the interest Of simplicity procedure definitions in procedures are 
forbidden. However, Wer«rch*cal rresting of stttemem grc^tps wtthin a procedure is quite 
desirable, so it is allowed arkl encouraged. > >r 

What scoring of na%ei is pro^ 
procedures there is little reason to allow variable names and constant names to be obscured 
(reused in nested blocks), especially since procedures are not expected to be very large. 
However, it is often helpful tp restrict the scope of oittaw variable (or constant) names to an 
inner block, such as a loop, rather than an entire pre<edu£R^his help* indicate the purpose of 
the variable. .-.-.-■ 

Our no-global-variables policy makes programs more r modular, but make*: some 
programs a little mor,e awkward when global daU is rwcesjarju The maiaadvantag^of global 
data is not having to explicitly pass it to everf procedure; that might use it. An example of an 
object normally made global is the symbol, tabte of a compiler. Assume we must implement a 
compiler in a language forbidding global data. Ut us.say the compiler parses by recursive 
descent. Only a few routines directly access the symbol table; however, the symbol fable must be 
created at the highest level and passed explicitly through many routines that never use it at all. 
These intermediate routines only pass ^ We 



2. This has nothing to do with separate compilation, however. Modules may or may not be 
separately compiled: we do not wish to pin this aspect down. 
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feel the modularity gained by forbidding global data more than offsets Hie inconvenience of 
requiring extra writing for some programs. Removing gtobal data is essential to eliminating 
implicit rnodule interdependences. Block structure is not bad » itself ; global data is. However, 
once alt data is local, there is little point to Mock structure for module definitions. 

Even though ail data should be local, we argue that module names should be global. 
It is not useful to restrict the scope of modules, and m fact tt can be counterproductive - it may 
force abstractions to be re-i m p lem ented needlessly. Therefore we assume that module names 
are global. We neither require nor prohibit ether inf ormatian regarding the relationships of 
modii les - such module interconnection inf o r mation is beyond the scope of thia thesis. 

2.3. Procedure Invocation 

The previous section discussed variables and constants, the mechan isms for storing 
and holding objects. We now continue, with procedure In w (w ition, which a Hows the creation of 
new objects *ndtb£mau^ 

2.3.1. The Different Classes of Argument* 

The who*! point of procedures is to gain absti action irr acttorrs. A set of actions that 
form a logical whole is grouped together and 1 vleiid a* * singfc abstract action. The basic 
actions are mutation of objects and assignment to variables. Since all data is local in ASBAL, 
the key to procedural abstraction will be me artj^ment* passing mechanism; that is, the 
rn-^Trirm *-j rtUrfi (irnTritifrri irr ^lirir iiriiii tli ifllif l» ipwiiTt tipiai It: 

We can imagine asf many ar four dtfreVent ctasses-Of arguments ta ASBAL. The first 
class is constant arguments. A constant argument to a routine H in Input which cannot be 
directly modified by the routine. We -*# see later that a proosdure cannot count on an 
constant objwt's not changing state, because there may be an access path from some other 
argument tw the object that allows it to be mutated, flu w e > «, hi the absence of pointers, a 
constant argument cannot be rmnated oy me calhri piixadUit aw A^BAL. Funhernwre, if all 



1. We reserve the word patamttr for a future use, and carefully distinguish between 
arguments and parameters, 
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arguments to a procedure are constant arguments or result arguments (see below), then the 
procedure is functional; that is, it does not modify any of its arguments. 

The second class of arguments is object arguments. An object argument gives access to 
a particular object, allowing observation and mutation of it However, the variable containing 
the object may not be accessed, and therefore may not be assigned to. 

The third class of arguments is variable arguments. A variable argument is a variable 
passed by reference. Therefore, assignment to it is allowed, as well as access to (and mutation 
of) the object it contains. The difference between variable arguftents and object arguments is 
exactly the difference between assignment to* variable and mutatton of the object it contains. 

The last class of arguments is result arguments. A result argument is, a variable which 
may only be assigned to. The purpose of result arguments is the construction of new objects in 
variables, that is, assignment. This includes initialization as weN as assignment. 

"■ • 'V r ■ V- '■ ■ <' ' n- ■■" "-?*"$? '?■'■■- ?■■■ '; 3. :?'=** ' ( ^ t «£■ !■■■: ■' '" *'■ "' • ■ ' : 

Object and variable arguments (the second and third classes described) are not very 
much different from each other in implementation. Both would be implemented by passing by 
reference. The only difference is that a variable argument may be assigned to, and an object 
argument may not be. This slight distinction is not worth the complexity of two separate 
argument passing modes. Therefore, we chose to dispense with one and keep the other: we 
retained object arguments, and eliminated variable arguments, for two reasons. First, this is the 
more conservative choice in that less access is given to arguments. Second, object arguments 
more like CLU's argument passing mechanism. In CLU, object references are passed, by Value. 
The effect is as if immutable objects were passed by value, and mutable ones by reference; 
except, the variables of the calling procedure cannot be affected by the called procedure in any 
way. However, the object passed is shared between the procedures,' and hence mutations of it 
performed by the called procedure will be visible to the calling procedure. The decision of 
which class of arguments to keep is not all that important in the long run, but has affected 
later decisions such as the selector mechanism and aliasing detection. 

Now that we have settled on th<e classes of arguments - consttnt, object, and result - we 
need to devise a syntax for expressing procedure definitions and invocations. Let us first 
describe * simple scheme which we wiH improve tipom in a moment. 
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2.3.2. A Simple Scheme 

The simplest approach to defining procedures is to hate a header hi each definition, 
much like the procedure headers of ?*scat In me header we stale the local name, type, and 
class of each argument. For example: 

p - proc (const wjt: Int. tar f. array lint}, res t: beoD; 
The above header says that procedure p takes four arguments: two constant arguments, w and 
x; one object argument, y, and one result argument 1 The procedofe p is not allowed to mutate 
or assign to a; and x (integers are not mutable objects anyweyh p may mutate % but not assign 
to it; and p must assign to z, but may not access it beforehand. Calf by reference is used to 
implement aft three kinds of arguments; the difference between them is in what the called 
procedure may do with an argument - not how the argument is passed. 

Procedure invocations take the usual form-. M*e name of the procedure followed by a 
parenthesized list of arguments. For example, a call c4 the procedure p used above might took 
like this: 

p (1, i+5, -%, b); 
The types of the arguments must match those declared by p. F u rt he r m or e , access constraints 
may not be violated. Thus constants may not be passed as rar a rgument s, or expressions as res 
arguments. 

2;5.S. Returning Values vs. Passing Variables 

The simple scheme outlined above is perfectly workable, but caw easily be improved 
upon. The main thing to notice is that there is no explicit ass^nmcm M ast^nmewu are 
accomplished by passing a variable by res. (Presumahh; Jhe bolk-^ types have operations to 
assign to a variable of their type. In a sense these operaticeis .aw magical, since all other 
assignments rely on them.) However, the procedure in vo c atio ns ne ce ssar y for each assignment 
are tedious to write out in the simple scheme, and tife? obscure what ts happening since result 



1. We admit the use of vac for object arguments is not the best, but wf was used to parallel 
Pascal. Anyway, we do not wish to get involved in purely syntactic issues. 



■*#?"' 
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arguments do not stand out. 

It is possible to separate result arguments by writing them on the left-hand side of. a 

':-' symbol, to signify assignment For example, we would write: 

var b: foo, c bar; 
b :- q (x, y); 
c :- r (r); 
a:-p(b,c); 

where in the simple scheme we would have written: ,, 

var b: foo, c bar; 
q<x, y, b); 
f (i,c>, . 
p(b, c, a); 

assuming these to be the types of p,q, and r. 

prproetyplCrir foo, bar, re* TB 
q: proctype (var T2, TA res f oo> 
r: proctype (var T4, res bar) 

The use ctf V shows more clearly what fr going on. 

We can make a further improvement, however. If we had to declare a variable for 
every temporary resiu^, our programs would beopme quijtocMttered with extraneous variables 
and declarations. We can get around this problem by haying the compiler allocate temporary 
variables. Adding this feature allows us to rewrite the above example and eliminate the 
temporary variables. 6 and c: 

a :- p ( q(x,$, rii) ); 
Further, if some procedure returns a result we never use, we need not assign the result to a 
variable; the compiler will allocate a temporary variable, CQf tHe procedure to write into, and 
then the temporary will be thrown away <i.e, never accessed again). So, if the variable a were 
never used again in the example, we could eliminate it, giving: 
p ( q<x,y), r(*) ); 

The end result of putting res arguments on the left, and having the compiler allocate 
temporaries, is syntax quite similar in appearance to CLU. In fact, we encourage the 
programmer to think of procedures as returning objects instead of being passed variables to 
write into. The overall picture of this final scheme is that the calling procedure gets the effect 
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of objects being returned, and the called procedure sees variables which must be assigned to. 
This is a good compromise between abstraction and ef ficiency. The only constraint is that the 
sire (or at least an upper bound on it) of ail objects to be returned must be known before the 
call, so that the actual variable used can be created. How we deal with this constraint will 

become clear later. 

To encourage thinking in terms of returning objects, we put the description of what a 

procedure returns in a separate part of the procedure header, as in 

p - proc (const w,x: int. vary: airaytintftretWa* % SoSlh f 
The objects to be returned are given names because the procedure being defined views them as 
variables. Therefore, we now call the result arguments of a procedure wfum 4«rfoM«. Notice 
that effectively all we have done is segregate the f» arguments. 

Now let us consider how to express the returning of objects in ASBAL. .In principle 
we could use a return statement like CLU's, which give* a Urt of objects to return. This would 
be implemented by implicitly doing assignments tb ;tfteF ^ t^Smi rvaViiole* However, these 
implicit assignments might involve the copying of large objects into the return variables. 
Instead, we allow objects to be built incrementally in «W return variables, and simply say 

return; 
to return from a procedure. We view the return variables as belng^uninitianwd on procedure 
entry, and any return statement in the procedure is considered* to be a use of all the return 
variables. This allows us to use whatever mechanism already exists for totting the use of 
uninitialized variables to handle return variables as wen. th "sum thin, "the underlying 
mechanism of returning is the passing Of variables (whether tnefoe programmer declared or 
compiler created*'.' However, we tffirofTthe syntax -M^m^i^^m^mik of returning 
objects, a view we feel is more natural' 

2.3.4. Multiple Returns 

In most languages, procedures may return only zero or one things. We remove this 
restriction because it is arbitrary and sometimes counterproductive, in that some procedures 
most naturally return more than one object Of course, we provide suitable synuctic forms for 
using this feature. The return statement itself need not be extended since we are depending on 
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assignments to get the return objects into the return variables, as previously explained.. 
However, some syntactic form is necessary to designate the variables to receive the return 
objects. The multiple assignment statement, which will be discussed in detail in the section on 
assignment, is used for this purpose. Its general form is 

varf, vox 2, -, var n :- invocation; 
The header for a procedure returning more than one objict would have a returns clause of the 
form --■'■■*" " ; 

returns (varj: typtj, .... var n : type n ) 
where the types may be factored. For example: 

returns (x,y. int, z: char) 

The order of the variables oil {he left *sd< Mk th# multiple assignment statement is the 
same as in the returns clause of the procedure header. This parallels the standard 
correspondence of actual and formal ar gu me nts to procedures. The returns clause may be 
omitted for a procedure returning no objects, or 

• returnsO 
may be used. 

2.3.5. Aliasing 

We have not dealt with the problem that arises when the same object is passed to a 
procedure in two different var positions, or in both a const and a var position. The problem 
is that not alt procedures are prepared to deal with ov trlaf p ln g variables. The problem is 
compounded by the fact that there are variables that <eff actively) have subvarlables (e.g.. 
records and »r*ays), and overlapping subvartabtes pre se nt the same difficulty, furthermore, 
the fact that each argument has a different name in the catted procedure tends to make people 
forget that two names might refer to the same object (or overlapping Ob jects). We call the 
problem aliasing (after Eudid ELampsonTT)). We beMevtf that abasing should be Illegal ' One 
very good reason for> prohibiHng auasing is ths4 it can cautt an argument to mysteriously 
change into an entirely different object from that passed. Consider the following procedure: 
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p - prod*: arraytt], x: t); 

aUOl :-...; 

aCil :* K; 

end p; 

It is reasonable to think that U) p ha* no ef to on x stnos it c^ iwt assign to it in the body, 
and <b) that after the second assignment, efJJ eouab tht acfomaM passed In. However, one 
could call f in this way: 

p(b. bUM); 
Assuming that both argunwnts are paised by reference, we. so* tiw4 the assignment to ef JM in 
the body of p can destroy *v Sea tL amp sa nTB fief, to^ s»g«|*eilt» as to why a«*stng should 
be prohibited. 1 

Most otn of aliasing can be ds saetsa at s obu j h s Quaay but some re q uire ., sample 
run-time cheats, e.g., that two army Indexes are dtffaraat far Hw aa B 

f (a[fl, a{ jW; 
and so on. We win explain what most be done to prevent abasing hi the section on 
implementation, and will expand the filial to cover fsawei tttot impact on abasing as we 
encounter them. 



2.4. Assig itment 

Here we describe hew to change 
commoniy called miigtmmL As 
procedure invocation, return variab hi Iwhttti 
alignment meehanism. it^ a*** to see 

var .- invotatim. 
that fa varlabta* being assigned a compute s ! 
procedure catted, '(pfewttl 



ofefcrt is atored #t a vartobat - the operation 

*- -was dascsssalM at awjruriiaa* - passing and 

are the only 



taw vaaas^ispaiiui to the outermost 
rli'Haf fjM eayaasstons ate realty invocations, 



1. There are no implicit arguments in ASBAL, unHfce Eucttd. This should reduce the number 
of checks required to prevent aliasing. 
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even if they are not explicitly written out. For example, 

x ♦ y 
really means 

T$add(x,y> 
where T is the type of x.) What about assignments of the form 

var 2 := varg, ? 
There is no invocation there to pass varj to! This problem can be handled in three ways. 

First, there could be a system-defined, automatic copy operation performed. This is 
what happens in most languages. Ignoring differing storage formats, etc, the implicit copy 
performed is essentially a bit-f or-bit copy of the contents of the storage allocated to 1)0*2 into 
the storage of varj. We call this operation a bit-copy. A btt-copy works fine in the absence of 
abstract data types, but with their introduction a problem arises. Any assignment creates a new 
object; a bit-copy creates one with the same state a» the one in the right-hand variable. The 
problem is that not all types should be copied in this way. For example, some types may require 
all the existing objects of the type to have different states, so that each object is detectably 
unique. In the presence of pointers, it is not clear whether a pointer which is a component of 
an object to be copied should itself be copied, or whether the object pointed to should b* 
copied. 1 Thus, an automatic copy primitive is not feasible. 

The second solution is to have all assignments 
var :- exp; 
mean 

var :- T$copy(«c£); 
(where T is the type of both txp and par), whether txp h a variable or an invocation. This 
has the unfortunate effect of doing a redundant copy whenever txp is not a variable. 
Furthermore, the redundant copy operation is hard to optimize away because usprs write the 
copy operations, and are not constrained to make them easily optimired. 

We feel the best solution is to insert no extra copy in assignments of the form 



1. This is called the copy problem and will be further discussed when pointers are added to 
ASBAL. 
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var :- invocation; 
and to take 

varj :- var^i 
to mean 

var j :- TScopy (mr^i 
The type of Tfcefy is assumed to be 

proctype (const T) returns CD; 
If an assignment of one variable to another is written, and the ap prop r iate copy operation does 
not exist, then the program is in error. 

Let us point out a few con sequenc es of the 'sotottm we have adopted. First, every 
operation must provide a copy operation if objects of die t|p« are to be assi gne d from one 
variable to another. There is no getting ae o und Oris; the second solution bod it also, and we 
demonstrated the first solution to be fetfeasible. S econd , die V sym b ol bos a non-uniform 
meaning. While we sympathize with those that bebeve syojbob should have dearly defined 
unique meanings, we feel we most com p romise that priacipbj in this case. What is gained is a 
savings in effort at optimization, or computer time in progeam ^ 

There is one more probl e m with aisjgoments: conokb 

X :-p(x,y>; 

Here p receives x as an argument m two positions; one is readable, and one is write-only. 
Things could get really messed up when p starts to write into its return variable. One way to 
solve this problem is to translate it to 

x :- T$copy <p in, y»; 
similar to the solution of the previous problem. Inse r ting a oaoy here tea bad idea, though, 
because it is nowhere near as obvious as before when an extra copy wi& be inserted and when 
it will not. The better solution is to attocate a temporary variable and pots it to p. Then after 
p returns, a bit-copy is performed from the te mpor ar y into x. A bit-copy works because the 
state of the object in p is exactly we state desired for the now object in xj fu rthe r m ore , the 



object in the temporary is never accessed again. 
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2.4.1. Multiple Assignments 

In a previous section we introduced the idea of returning more than one object from a 
procedure. We need to be able to assign those objects to variables. The form of assignment 
statement for this is 

var j, var 2, ., var n :m invocation; 
To extend this to its logical (and useful) conclusion, we also allow simultaneous multiple 
assignments of the form 

varj, var 2 , .... var n ;* txp], txp 2 , ~, <xp n ; 
Each variable var t is to be assigned the corresponding expression <t*pp and all these 
assignments are to take place simultaneously. To prevent confusion we require that each 
expression either be a variable or return only one object In case of aliasing, the same trick of 
using temporaries works fine. For example, in 

x, y :« q <z, r(y>, x>; 
a temporary would be allocated for the result destined for x. On the other hand, one is not 
needed for y, because y Is not ah argument to f 

One particularly nice construct the multiple assignment statement allows is 

x, y:-y, x; 
It is hard to decide if this should just swap the bits of the objects stored in x and y, using 
bit-copies, which is both efficient and semantically correct, or whether it should invoke ttcopy 
twice, 1 which is more consistent with our above rule about assignments between variables. We 
believe it is better to be consistent (i.e, to caU t$co$y>- A. new operator could be used to swap 
the objects in variables, but we will not exptore such possibMUies here. 



1. For "x, y :- y, x;" two temporaries might be required; however, it is not difficult to have a 
compiler notice that one of them is not needed. 
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2:4.2. Declarations with Initialization 

One last useful assignment statement is a declaration with initialization (or assignment 
with declaration). This form of statement aHows one to declare and assign to a variable in one 
step. Here are two examples: 

var x: foo :- p <z); 

var x: foo, y: bar :- q(t), r(u); , 

A declaration with initialization is effectively 1 a shorthand for a dOCkratton followed by an 

assignment. Thus the second declaration above it acairVitWr to 

v«r x: fbo; y: bar* 
x, y :- q(t). r(u); 

which is in this case equivalent to 

var x: foo, y: bar; 

x:-q(t); 

y :- r(u); 

Constant definitions, which were introduced in a prearun** section, have the same effect 
as declaratJoni with initiaJixation. The onry difference it that • cawaranti can never be assigned 
to again. 

2.5. Access to Components of Objects 

The previous sections of this chapter have desk wKb me di an Urns for manipulating 
objects as a whole; here we discuss the additional mectanU n w necessary for manipulating 
components of objects. There are three actions that 'x*m^ ^ti *> m i A tm'db$Kltx- objects may 
be created, they may be observed (read), and they may be mutated. We desire to be able to do 
all three to components of objects as well as to entire objects. Creation is no problem. A 
component of an object is either created when the object is created, or is created by a 



1. In Chapter 4 we will see that there can be an important difference between a declaration 
with initialization and one without However, for now, consider the declaration with 
irrittatiziiroh to be equivalent to a dectemtlon foHewed by an Inttkltzatlen. 
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(mutating) operation on the object. Records are an example of objects whose components are 
created with the objects themselves. Arrays exhibit the other behavior: the addh and addl 
operations allow new array elements to be created dynamically. (Records and arrays will be 
described in more detail in a moment.) Abstract data types may display either or both 
component creation behaviors; they may always possess some components, but create (and 
possibly destroy) other components dynamically. 

Reading components is already taken care of as well. Since all objects having 
components are built from records and arrays, and records and arrays have operations to read 
their components, any type can provide operations to read any components it may have. Of 
course a type may not make alt components available externally, and may return information 
derived from the components rather than the components themselves. However, reading 
components. is always done by returning objects. This is unfortunate, because returned objects 
are always copies - always new objects. (Remember that return variables must always be 
assigned to.) Thus, returning does not allow components of objects to be mutated; only copies of 
the components may be manipulated: 

It may seem that storing a mutated copy back Into a data structure is equivalent to 
mutating a component of the data structure, and this is often true. However, many data 
structures do not allow components to be replaced at will in this fashion. As an example, 
consider queues; perhaps we can observe the member at the front of the queue, but we can only 
insert new members at the end of the queue. An even better example Js items that must be 
mutated atomically rather than by separate reading then writing! semaphores and other 
synchronizing data types fall into this category. Copies are sufficient for observing 
components, but a special mechanism is needed to allow mutation of components, 

In a previous section of this chapter we indicated that the operations of an abstract 
data type are procedures. We now design a new kind of module,, the ftlectar, which is also 
allowed as an operation of a type. Here is what a selector does, A selector if given an object 
from which to select a component, and possibly some aw0QQ arguments tp describe which 
component is desired. The selector then proceeds to calculate whatever array indexes, etc., are 
required, and eventually executes a select statement The select statement indicates the 
component object to be made available for use. What is returned to the caller of a selector is 
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not a new object, out rather a descriptor of the cantporMB* selected. (That is, an object 
reference is returned!) The selected com po n e nt may be used at, a oar aifuuvent to a procedure, 
and can thereby be mutated. However, what la selected is an tkjtct, and hence may not be 
assigned to; only variables may be a ssign ed to. 

Since a reference to (descriptor of) an object J* returned by a selector, we must guard 
against any dangling references. PotentiaHy, a selector comM select one of its local variables 
rather than a component of the object ir it supposed to select from, gWing rise to a dangling 
reference when the descriptor is returned. We prevent this by rearing that selectors never 
select any of their local variables (^ returns 

cannot create dangling references of this sect A pro c e du r e always creates a new object, in its 
return variables; procedures can never store object ref ere n ce s in return variables. 

There are two minor points to mention reg ar d ing mutability. First, components 
selected from var's should be vat; i.e., mutable, and, components of const V should be const. 
Therefore, a selector does not designate whether to object .sat select from is const or van that 
property is automatically inherited from the tncommg object Fu rthermo re , a selector may not 
mutate the object being selected from; hence the object it treated as a const inside the selector 
for checking purposes. The second point is that a selector shook) not mutate any auxiliary 
argument. Therefore, a41 a ax inary arguments are Uken to be const 

The form of a tt/cctor <fe/?nitt*n is: 

name - selector (nanu^- typt Jt namy typ* 2 . ■, nami^ ttft^ of *jgu from name^ typ* . 
, stattmtias; 
end name, . 

The name i for i > are the auxiliary arguments; ttwaep is the object to select from. The "of 
typ«' part indicates the type of the object to be stke n ui A sestet statement (whkh is only legal 
in a selector) 'rales this fortli ''"'' "' 

•sd&ct exprexsteti;^ 
The expression cannot designate a local variable or auxihary a rg u m e nt of the selector. 

It is harder to decide on the exact form of a ofecnex. uW eonstrutf that invokes a 
sefector. We cbuW use .;*.>•■■<■■■■■:. 

s€lecTor_name{obJect to itlta from, auxUlary arpmtntsi 



35 



to be like procedure invocation, but we feel it is better to write 

object, selector _nameiauxillary arguments) 
to be analogous to records. The latter form also has the advantage of making the object being 
selected from stand out. If the selector takes no auxiliary arguments, the parentheses may be 
omitted, leaving 

object. selector jname 
which is just like a record component setectton. 

In many cases computing a selection can be expensive. Therefore, we provide a 

mwhanism for saving a selection; ft Jj the with statement: 

with class name -■ exp do 
statements 
end with; 

where class is const or var. If the class is. var, then the selection must be from a var. The 
nam<? stands for the selected object with m the body of the with statement, and is treated 
according to the declared class. A scope is used bemuse extra checking must be done for safety. 
To prevent mutations Of the containing object from destroying the selected object, all 
arguments to invocations in the body of the with statement are checked for overlap with the 
selection. '"' 1 '■ ■" 

For example, say (rjourKted) queuej are implemented as arrays. If the front member of 

a queue is field in a saved selection, then the queue may not be modified until the scope of the 
with statement is exited. This is because an element of an array <the front member) overtops 
with the array itself (the queue). The checking to prevent this aliasing Is done using the 
normal aliasing detection techniques. (The checking may be difficult to accomplish at 
compile-time, however.) The with statement it similar to the fcad Operation in Euclid. 

Now that we have described the essential nature of selectors and selection, let us discuss 
where selectors are appropriate and where they are not. Selectors are to be used to mutate 
objects stored in a surrounding data structure wtehout distUrtJIng that strurt^ The types 
having selectors win usually be ones that store data Items and relationships between them, but 
do not manipulate the data items directly. Good examples are ttsjts, stacks, queues, trees, graphs, 
etc. Selectors should definitely not be used to access oumuon e itu that cannot or should not be 
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mutated. Furthermore, selectors should not be used merely to make access .niore efficient, 1 for 

this can lead to {effectively) exposing the represe^atton and thus tenit the range of 

implementations of a data type. For example, consider the functions ml, im*g, #**, and erg on 

complex numbers. Implementing any of these functions as a selector forces that component of 

complex numbers to be represented explicitly in the r e pre se nta tion. Hence, selectors threaten 

the uniform reference principle [Geschke75, Rossf93. Thus, the specif ier of a type must use 

caution when deciding whether particular operations should be procedures or jeJectors. 

We now describe records and arrays. It is important to understand their semantics, for 

they are the principal types used in defining representations of abstract data types. A record 

type has named fields, each specifying a type. For example, 

recordta: int, 
b: bool, 
c: ralph] 

Each field name defines a selector with the specified name; the tjf»e. of the selector is 

sehypeO of type cffitM (rem word typ* 
Record components may be changed- The operation ^put^W_mrau' tt used to update the 
named field of the record. The, Qrne of 'pal Jield^name' ii 

proctype (var rtterdjtjpe, const fleld-typt); 
The new object is constructed using the jfteM_fy£#$copy operation, which must exist for 
Jifld^type to be usable in a record. For convenience, record pur operation h^ve a sugar; one 
may write 

exp J field-name :- exp 2; 
instead of 

recordjtjpe%pulJleldjMme {**Pj, **$$'% 
Notice that record put operations are "hiagiear atomic mutating operations. Records also have 
copy and equal operations; records are more fully described in Appendix II. 

The only other operation on records is creation. ThU cannot be written out without 
giving an order to the fields. We feelit is better to think of the fteWsas being unordered, and 



1. Selectprs do save a copy operation over procedures returntng an object 
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so the user may not invoke the record create operation directly. Instead there is a special form 

called a record constructor which' allows creation of record objects in an order-independent way. 

A record constructor takes this form: 

record jtjpetKfleld-namtj: expj, 
jfiteW_n«m«2- **p2> 

fleld-.nam* n : txp n ) 

The field. names mm *M hevpres§f^exaalj( ^^^MblMIPf '-41^.7 •?!>* IfcM 1 *f0.^comp*WBd in 
the order listed, 1 SevwaWj^ds may £« IniUaJi^^o («^i«*of) thesamaoKr^W w »1Ung 

.. field^nam^fiel^^jMm^^Jl^^ »> -:-.--.: ; - s : -> 

The record constructor invokes tr>e appropi^aM «V? °P^*<^» f » »^ h wpr«s»ic« whkh is a 
va riabte. and for t»ch expression wtych^ te£ijn*1*$«^^ ^ , , 

An array object is a sequence of objects, of a single type, indexed sequentially. The 
sequence may be empty, and can grow and shrink In size dynamically. Arrays have a selector to 
index them; it is called fetch, but there is a shorthand for indeking arrays. If an element with 
index l currently exists in the array a, then AQ selects that element as does the unsugared form 
a.fetch <*). 

An array variable can hold only certain array objects of its type. More specifically, 
each array variable has associated with it an interval of the integers, and only arrays whose 
indexes are all in that interval may be stored |n the array variable. (We emphasize that the 
indexes of an array object and those allowed for an array variable are. bj^th sets of consecutive 
integers.) The allowed indexes for an array variable are, set when it is declared, and never 
change thereafter. Thus, an array variable of type airavlfoojtpw.high) can he assigned, any 
array object whose elementt are foo's, and whose indexes are all greater than or equal to low 
and less than or equal to high. The type of the array object is ||ravjfpp) f (This difference in 
the number of parameters and the V notation wiH^exoh|ne^^n^e chapter on parameters.) 

There are operations on arrays that allow ^dding, and jreiDjf|ng elementt frorn the 
high or low end (i.e., growing or shrinking the arryy one element at a time at either end) laddh 



1. For ASB AL to be well-defined, the order of evaluation is always specified. Unless explicitly 
mentioned, that order Is left to right ' ; .<- : -^s ^.v^ucwi ;.-,- .-.■■=>; ^-■-■j .v 
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and addl), trimming to a particular range of indexes <M^, oueryittg the size (ilz«), km index 
(low), and high index ikigte, shifting the element* CwC/ow), ar*d replacteg the elements Or or *>. 
This last operation, rior*, has a sugar simitar to that for the record put o per ati o ns . We may 
write 

expfexp^ -.m expy, 
in place of 

array_ry^e$store <expj, txp2> **p£> 
®o$h forms mean ^replace the component at Index number *xp2 in $kt * rr *T **?/ *** a co PX 
of *xpy. See the appendix for a complete hst of array *^«io^%fieiitt4ons. 

Arrays were designed in thh (somewhaf onosttaA way to he conrenient for use as 
representation* of abstract data types, and to prevent access to u n in iU al lted elements. However, 
they are a bit rrwr« ex jmisive than arrays foond in most pmsjiammin g languages, in space, and 
in time. 

2.5.1. Examples of Selectors 

Suppose we had an abstract type MssoctiUioejmmorf, which associates pairs of integers. 
We represent an associative memory as an array of records; each record has two components, 
one for each integer of the pair. Thus the representation type of the associative_memory 
cluster is 

arrayC recordC first, second: int]; 1, 1003 
assuming a maximum of 100 elements is allowed. The assodauve memory is to have an 
operation tpdau which mm change the second element of a pair, based on die first element. 
Update will have in it a statement hie 

a[ index Lsecond :- new; 
which is a sugared form of 

RT$put_second<a.fetch(index), new); 
where RT is 'recordtftrst, second: int]'. Thus, we have shown how a selector may be used 

Let us now consider an example of a type providing a selector itself : a bank account 
record file. It is convenient to design jhe structure used to access the individual accent records 
of a bank independent of designing the records t hemselv es. Of course the two designs 
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interface in the area of the keys used to search for the records; but except for the keys (and the 
size of the records), no properties of the records affect the design of the access structure. 
Likewise, the access structure has no real effect on the properties of the records- Let us suppose 
the file of all account records is a (rather large) c4> jKt of type oobimjl/U*, and that the type of 
the individual records is account-rtcord. Sine* «efeiiiW.4tiuttdr are mutable, we design 
accoan/^/W* with a selector of type 

sertype (keyjype) of account_reeord from account Jile 
This allows us to realize the separation of access from Use. This separation contributes to 
abstraction by reducing dependencies among different 1 types, fh the absence of Selectors, we 
would be forced to implement all update actions on account records as operations on account 
files, and present the appropriate key every time. Furthermore, the access would have to be 
recomputed every time Thus not only are more type depe nde n cies created (by making all 
record updates go through fife o p erat i on s ), btrt per fo r ma nce is reduced as well. (Remember, 
though, that performance arguments alone do not Justify tiring » selector.) 

On the other hand, if a selector is used to access the records, then a restriction is being 
placed on every i mplem e nta tion, namely, that account records must be represented explicitly in 
account files, and that * must be pc«ible ft>r programs to access account records directly once 
the records have been selected. 1 

2.5.2. Summary 

We have presented a new module, the seltctor, designed specifically for ASBAL's 
object interpretation semantics. Selectors allow components of objects to be selected dynamically 
and passed to procedures to be mutated. A type has the ultimate control over the components 
of its objects, and need not allow them to be selected. Furthermore, only the object can change 
the identity of its components, since selected components may not be assigned to. (Selections 
produce objects, not variables.) Records and arrays were introduced as prime examples of types 



1. Notice that selectors do, not solve any of the *robJems assocUM. with accessing objecjts on 
external storage, ASBAL assumes all objects exist in a, sing^^untformlyaccesaibte address 

space. 
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providing selectors. We argued that selec t ors are \ nta pi iar p .tout age ao he used sparingly so as 
to avoid having types depend on waving a particular re f Hewmatton . 

2.€. Implementation 

Now we come to the question of how to implement all of Unaefeatiu**- 1 f%st, we are 
going to allow recursive (and mutually recursive) proceduret, ao aateok of proc e dur e activation 
records is required. These frames (as we ate call ^ act l f alhm ^esowts) ape very much like 
those used to implement languages such as Algol and !>JaVs> Each frame contains the storage 
for the (local) variables and, temporaries of ihe pii?etd<im «cttf at tan ia wh*ch it corresponds. 
Since a finite (and usually small) number *f vafitalHeiafe uaadi»«^Mcadure, it is possible to 
give each variable a fixed of faet f rom the beginning of I*hc fmwwv which can be very efficient 
on many machines. As for arguments and return variaoks* they w#l toe passed by address. 
The slots for these addresses can also be at fixed (p atiibly nffitivuVoWseti^rom the start of 
the frame, since the argument addiesses inay be p^ 
procedure before the frame is created. 

Using fixed of f sets in this way f»ib only for local, v art a to lm and tempora ries whose 
size is not known at compile-time. (However, d«a*ptora wim slots for painter* to those parts 
of a variable that are allocated at run-time, can sttfl be stored at #iae4*e#feeU from -she start of 
the frame.) Most types have a fixed site, and we will not discuss the mechanisms for using 
types of varying size until the chapter on parameters. On the other hand, ''/^m present the 
implementation now since it affects other parts of the design of ASBAL. 

Most cases can be handled by simply allocating die required amount of storage on the 
top of the stack as soon as the size is known. (This storage is accessed through a pointer at a 
fixed offset in the frame.) There are only two situations where this does not work perfectly: 
declarations with initialization, and temporaries hi the middle of expressions. As we wiH see 
later, the size of these variables may not be known until just before the procedure which is to 



1. We assume the reader is fairly familiar with i mp leme nta tion techniques for stack based 
programming languages, so we t>ften gkm over detafe tturt s^ iwt twvet and do not present 
special problems of m u ^w ei ftsflj on. 



{■■'^^mm^sA 
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initialize them is invoked. Unfortunately this is afti arguments to the invocation have 

been computed; if any of those arguments are themselves temporaries, then allocating the space 
for the return variables at the top of the »tack will-renrtt m a *hole" when the temporary is 
freed. Let us present a simple example to demonstrate the creation of these holes in the stack: 

var X: foo :- p (q(y), r(z)>; * ■[ "*"" 

where the size of the foo is not known until just before p is called. 

(1) The stack starts as in part (a) of Figure!, wirtry and * in the current stack frame. 
<2> A temporary variable t_q is allocated, and q narHe<HH>>. 

(3) Another temporary <_r is allocated and r is called <te). 

(4) Space for x is allocated and p is called (Id). 

(5) The stack is left as in part (e) of Figure 1, with a bote befween x and the rest of the 
variables. 

Thus we see that the simple scheme will leave holes m tmrstack. There are three solutions to 
this problem. The first is to ignore it; this is not a good idea for more and more holes could 
accumulate (e.g., in recursive caNs) and cause considerable waste of storage. Still, it is not clear 
just how much storage is wasted, and it may fiot pay to prevent this particular waste. The 
second solution is to bit-copy the new variable after it is created, moving it to the beginning of 
the hole, and thus eliminate the hole. This need rnrt be Inefficient in terms of code because 
many machines have a suitable block transfer instruction; however» the copying might use up 
considerable processor time and memory cycles. 

The third solution is to use two stacks rather than one. The basic idea is to allocate 
temporary variables on one or the other of the two stacks so that neither ends up with holes. 
Let us call the stack with the Usual frames and focal variables the variable stack, and the other 
one the auxUtarj stack} It is clear that in orderJte end up with no. holes on the variable stack 
the temporaries used for a call must be on the auxiliary stack. A symmetric argument leads to 



1. The auxiliary stack will have to be set up into frames as. well, but its frame pointers and 
stack pointer can be saved in the variable stack. Thus all housekeeping information is kept in 
the variable stack with the auxiliary stack used only for storing temporary variables. 



42 



Figure 1. Scwierto of Simple AbmMkm Scheme 
£x«utionof V«rK:f«o:-p <ejty),rti»;' 
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the converse fact: that to avoid holes on the auxiliary stack, temporaries needed during the 
computation of intermediate temporary values must be put on the variable stack. What 
happens is that we alternate between the stacks according to the nesting depth of a particular 
temporary in an expression. Let us examine another scenario to illustrate this scheme. We will 
go through the execution of 

var a: foo :- p < q(r(), s(t())) f ti(v<» ); 
The evaluation is strictly left to right. Figure 2 shows a sequence of relevant snapshots of the 
stacks! It is not at all hard to figure out which temporaries should be put on which stack if one 
works backwards from the desired final configuration. Note also that the use of the two stacks 
is purely for the evaluation of expressions within a procedure. Any procedure that is called 
during the expression evaluation can put its local variables and temporaries on top of either 
stack so long as it cuts both stacks back to their previous state befot* returning. Notice also 
that both the one-stack and two-stack schemes handle multiple returns easily, by allocating 
more than one variable at once. 

It is not too hard to see how to implement two stacks on a computer: one starts at low 
addresses and grows upward, and the other star** at high addresses and grows down. There is 
some time and space overhead involved in keeping two stack pointers and frame pointers 
instead of one each, but there are no severe technical problems. So, we have seen that two 
stacks are better than one. 

2.6.1. Variables 

In either scheme (one stack or two stacks*, a variable is a contiguous block of storage, 
at least conceptually. For variables whole size is known, storage is allocated at fixed offsets 
from the beginning of the frame (in the variable stack). For those whose size is not known, 



1. Implementations of Algol 68 have many of the, same difficulties found in ASBAL. (See 
[Branquart70] for a description of the problems and their solution.) For example, some space 
reserved by loc generators in Algol 68 is more easily put hi the heap than on the stack. It is 
possible to put all space from loc generators in the stack, but in ASBAL we must resort to a 
heap, second stack, or copying the space. However, ASBAL does have an advantage over Algol 
in that it does not need a display, since* it has no local procedures. 
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Figure 2. Scenario of the Two Stack Method 
Execution of Var »: f oo :- p< q(rO, s(tO». u(y<» >;' 
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space is reserved at a fixed offset for whatever information is necessary once the variable is 
created. This can all the variable's fixed size parts, and slots for the sizes and addresses of its 
variable size parts, which are filled in when the variable is allocated- The figure at the end of 
this section shows a possible layout for stack frames. 

2.6.2. Selections 

A selection can be implemented as a pointer to (or descriptor of ) the object ft denotes. 
Slots for these pointers are easily allocated at compMe-ttenelMcaMe they have a fixed size and 
are of finite number. Even better, the number of selections is apparent from the text of the 
program. Thus, allocation for selections is no problem. 

Checking that selectors do not seleet a local item, encyst more challenging. A compiler 
can perform the checks by analysis of the expresston given in the select statement of the 
selector. The expression must be the object to select fronvor (more usually) a selection. from 
that object. The ©the* checks (eg., that the auxiliary argume n ts are not mutated) are handled 
by other checking mechanisms with, no special casing. Saved setations <m the with statement) 
present no mow problems than regular ones, and are fcnptemented' the same way. 

2.6.3. Nested Blocks 

Instead of using a full frame for nested blocks, it is probably easiest to append their 
fixed size space to that of the enclosing blocks, making one large fixed size block. Of. course 
blocks at the same nesting depth can use the storage in different ways since pn|y one of, them 
can be active at once. The part of their storage that is unknown in size can be managed in 
stack fashion: allocated beyond the space for the enchwsfig block, and cut back when the nested 
block is exited. These are well known techniques, i 

2.6.4. Checking if Variables are Initialised 

Now we describe the chicks necessary for insuring variables are always initialized 
before use. First, let us see how much a compiler can check. It is clear that truly sophisticated 
checking might Involve complicated analysis of the control flow of a program. However, we 
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would like to keep the analysis to a rrtfnlmum. Exclusive use of m ailed "structured 
programming" control-flow statements greatly ilmpWiei the analysis, The critical feature of 
such statements is that the number of paths through a procedure is. kept to a manageable size. 
The compiler can keep a record of which variables are asttoned to in every Mock. From this it 
is fairly easy to combine the information, i 



<1) those definitely initialized at every use; 

(2) those def mitely wtintttattsed at seme 

(3) and those potoibty u n l n i Matis e d ataBme uaw, stol dsftolMh; m*tottaed at the rest. 



The first class is all right; the second in dtato i an sgoawott p ro gram, ami the hat class requires 
the insertion of run-«me checks. For aaeh een iah hj o f the em s o ws, t h e wwiaq» i allocates one 



bit of memory ^ the runtime stack frame to bemud ae an mdJtatoTof whether that variable 
has been initialised. These bits aH start m the ^ stole nx the afawayl late places on the 
questionable paths,code wiMbe g sae reu x l tosettheblt to1lwt^Stoto,OTtotest ft. Even if a 
variable is. used and asi to n a d tom many Pluses, trti»«tra au to i rtt be imm tid m only a few. 
This, along with the fact that the code U short tone or wo hmnml e u i on most machines), 
means that there is Httle run-time overhead. We feet that the overhead is welt worth it. 
particularly when debugging programs. Netke that mis same scheme checks for initialization 
of return variables; all we need do is consider those vartobles to start uninitialized, and view 
the return statement as a use of aH of the retitm vartabtss. 

S.65. Aliasing 

The checks required to prevent aliasing art stmJghtforward. They depend oh a simple 
inductive principle: if there is no aliasing when p r uosdw e f -is Ojmed, (U n none of its 
arguments or return variables overlap), and aN local variables of p are disjoint (none of them 
overlap), then we can guarantee that p introduces no aliasing in the invocations ft makes. The 
compiler does this by making sure that no vartabtas s u b w i ab ho are abased in the calls p 
makes. 

To implement aliasing detection we need a de s criptio n of which components of 
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variables overlap, and which do not. The Euclid report [Lampson77] gives a very detailed 
definition of which variables overlap in that language. We will be content with a less formal, 
more intuitive description. First, it is obvious that a variable overlaps with itself. It is also 
clear that a record overlaps with any of its components, and an array with any of its elements. 
This carries down thrcnigh all levels, so an array or records overlaps with any component of 
any of its element records. On the other hand, if two variables do not overlap, such as two 
local variables with different names, then none of their su bc o mp onents overlap either. When 
two variables overlap, one must contain the other; hence, when two variables do not overlap, 
they are completely disjoint. 

How do we extend aliasing deteaion to general selections? First of all, any selection 
comes from a particular object in a particular variable. We need only check selections from the 
same object. An object and any selection from it are considered to overlap. Selections from the 
same object generally require a run-time cliick. TO the two 

selections overlap physically in storage. The starting address for each selection is always 
available at run-time, but the length of each must be provided in addition to the starting 
addresses. 

In a later chapter we will extend aliasing prevention, to cover the use of pointers. Our 
aliasing detection methods are based on those Of EucHd [Lajrap* " 773 

2.6.6. Summary 

ASBAL requires one stack to be maintained by its run-time system <but may do better 
with two). The stack frame for a procedure activation contains the local variables references to 
the arguments and result variables, and housekeeping information (return address, old frame 
pointer, etc.). For most variables, fixed offsets into the current frame can be used. Some 
variables require a certain amount of descriptive Information (descriptors or dope vectors), 
mainly those whose size is not known at compile-time. Figure 3 shows a possible layout for 
stack frames. 

Argument passing is by reference, i.e, the addresses (or descriptors) of arguments are 
passed to a procedure when it is invoked. Returned results are simply extra argument 
variables; the addresses of the variables are passed. Most of the checking for aliasing and 
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uninitialized variables is handled easily at comfMhb-tim^ and the run-time checks do not 
amount to much code. We conclude that our scheme Is about as efficient as possible given the 
level of safety we require and the features we want in the language. 

2.7, Programming Example 

In this section we will present a programming example to help illustrate the 
fundamental ideas introduced in 'this chapter. «31%i example is a type definition, but since 
clusters (the form of type definitions) have procedure and setector definitions inside them, all 
three module types will be illustrated. Later we w» see that using more advanced features 
allows us to write better definitions for the ^pe ye now present, but at this, point we are 
restricted to the most baste of features. 

There are. two essential parts to a,t|oe definition in ASBAL: the rep (representation) 

type, and definitions for the operations. As in CLU, we group these together in a single 

module called the duster. The syntactic form is: 

type-name « cluster is names^ofuoperatimsuixported; 
eep ~r*p_iype, 
operation r .name - proc ... ; 

operatioiuname - selector -. ; 

end type^name-, 

The procedures and selectors may be mixed. There abp may be internal procedures and 
selectors; an internal operation is one that can be called Wty from within the type definition. 
Internal operations are distinguished by the fact that they do not appear in the list of exported 

operations. :' i 

2.7.1. Bounded Queues of Integers 

In this first example, the task is to define and implement a new data type, a bounded 
queue of integers. The operations of this type and their functionality are listed below. 
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create: proctype returns (queue) 
(creates! new, empty queue) 

insert: proctype (var queue, const tat) 

(inserts the Integer attbeendof thequeue) 

remove: proctype (var queue) returns (Jot) 

(removes the front member of the queue) 

isjempty: proctype (const queue) returns (hoof) 

(returns true if a«lontf«*<he queue Uomptf) 

is_fulf: proctype (const queue) returns (booD 

( returns true if and oaty# the queued fi>H) 

size: proctype (const queue) returns Ont) 

(returns the number of member tin the queue) 

These queues wtfl be bounded hi stte, and the maximum siw wfflbe 100. 



2.7.2. The Representation 



It is easy to decide what representation to use for this type. An amry of 100 integers 

will hold the members of the queue, and will be managed in circular buffer fashion. One 

index will be maintained: the position of the first member of the queue. The members will be 

stored in order of increasing indexes in the array, modulo MO. The site w» be kept explicitly. 

Thus our type definition will begin: 

queue - cluster is create, insert, remove, isjempty, tsjfuit, size, 
vep- record {firsbint, 

slie: tot, 

q: at*, 
at - array Mot; 0, 993; 

end queue, 



51 



2.7.S. The Operations 

We will write the create operation 4 Hit Wo *e? the fUstoomptmmt of the rep to be 

zero, the size to be zero, and fill the whole army vftfc zero*. rray ** fUI«d for efficiency; 

it does not matter what it it fitted with in this case) The entire create operWten is presented 

below: 

create > proc returns (q: cvt); 

q.;-t«p.<f*estre,> ' V . '■■-■■.■■■ -^ : - ..--'• 

*iie4 0;, 
q? atlfill (0, 0, KX»}; 

■- :inoV±r«ate;< , •••' '*; 5 ■-■■-i ; .«w,.«a; f " ; .->.,■:.'■ 

The notation cvt (from convert) indicates a varttbte or conibint whose type is viewed as the 

abstract type (i.e., the ' typflfrelng 'llomdf ImImS^^M -«a)SriU^ IwS ' tih*"'*iip type inside. Of 

course it is only allowed in a module defining a tJ5pV»»d .f^Tfefjfwfy tr fMyp« »y context. 

The expression ait/UHUou.num) denotes an array obja3,«fttff«|ipM eMNnt* are copies of I 

(made by using; r$coftr>. for all indexes in the range /sw to /•a^aajaj} Inchisive^ provided nuw 

is not negative. (Calling oft/t// with a negative third argument is an error, and what happens 

will be explained in the, next chapterJ Notice that ?here fc nc>retnrn s^tement in the procedure 

above, for convenience, the end statement of a procedure does an Implicit return. 

Let us move on to six*, Is-tmpty, and fe_/W/ v , v 

size - proc (const q: cvt) retnrns (s: lot); 
■ s :- qsize; ■■'>.'>■■ ■; ■ . ; V; ,; ,, • •. 

end size; . 

isjempty - proc (const q: cvt) retains (e boot); 
e :- (qsize -0); 
end is_empty; 

islf iill - proc (const q: cvt) retnrns (f; boot); 
f :- (q.size - lOOh 
endisjull; • 

Our integers and booleans are like those of any other language; details are in the appendix on 
data types. The use of '-' in qjtu - actuatty indicates a call of 'IntJequal (q.size. 0)'. This 
use of syntactic sugar allows us to extend symbols such as V, V, '-', '*', V, etc, to abstract types. 
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Full information on these sugars can aho he found in Hie 
Now let its write the iroert operation. 

if q^ize-iOOihcu «rr»r end tf; 

var Index: tnt j- <q/*rtt ♦ q*i**> // WO, 

q.size :- q.size * I; 
end insert; 

The '//' is a sugar for ryptSmod, that is, the modulo (or iHualndar) 

Notice the use of sugared array and rased 

chapter will present a mechanism for 

write trrcr to indicate that appropriate code ha* been 

The remove o per ation should now bcaeaay far jhe 




remove - prop (var g; crt) return* f nwinhjr int); 

' if ^.Site-iwitir^'AiirV- 1 -^ 
- «»OHli|»:«^4^ilrtft 
q:first :- <q .Nat ♦ H // »$ 

qsite i-q-iifir-ir' 



Finally, here arc example caiu of the operation CThe symtoT V to pteftx a*, a augur for 
type* not itxpr)). 

var q: queue :• queue$create(); 

if ~ queu<$i$_f uH (q) then queueSinsert (q, foo); end if ; 

if ~ queuetisjempty <q> then bar :- queuetremowe (q>; and if , 

var s: int :- queue$siie (q); 



This data type (queue) just happens not to use any nhctw i. However, there will be several 
examples of selector defmitiom in later i 
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2.8. Conclusions 

This chapter ha« dealt with the f umUnwnta* semantics of ASBAL. a language 
intended to prejerve aj many of the ib«ra«*on f«atu«» of CLU as is possible under the 
constraint of a stack-oriented semantics and bnpfenentatfen. Wt started with the notions of 
variables and objects. We then went into the semantics and the syntax for procedure caU and 
return. Aliasing was discussed, and rules formed to prevent' Hi o ccu rren ce , A satisfactory 
solution to the problem of uninitialized variables was prtsented, and an implementation 
outlined. Next, the mechanism of assignment wa* explained, followed by a discussion of 
component selection. After discussing [Implementation, we presented an example to illustrate 
these concepts. The groundwork has been laid for presenting more advanced features of 
ASBAL. The next chapter will introduce two new features: iterators and exception handling. 
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3. Two Extensions 

In this chapter we extend ASBAL by the addition of two new features - iterators and 
exception haNdHnf. Iterators introduce a new kind c* abstraction, and are Implemented by a 
new kind of module. On the other hand, exception hawdttnf Just compietes the previously seen 
modules; itchaagtttheMr'Ifeott^ them to specif y and 

deal with exceptions* cases. We » Ht p r esen t each feature as it is in CLU, and then modify it as 
necessary for ASBAL. ' 

3.1. Iterators 

A major goal of abstraction in programming is to move the programmer away from 
details and Into working at a high conceptual level. Procedures provide functional (or 
procedural) abstraction, and dusters provide data abstraction. Another useful kind of 
abstraction has been identified, the control okstntctton tLiskovT7, WutfTBbl. The only sort of 
control abstraction we wi* offer is a generattiauoij of looping cafed an Utratvr, based on the 
iterators of CLU. A loop has three basic parts: 

(1) generation of the sequence of data items to be operated on, 
<2> operating on the data, and 
(3) testing for completion. 

Iterators provide a modular way of g e n er ating die sequence of objects to be operated on. In 
CLU, an iterator generates a seouence of objects dud are passed to the body of a loop. The 
crucial point is that an iterator generates the seouence of items mcrementalty: one object at a 
time. This will be easier to understand by f c4towing through an example. 

Let us say we have an abstract type Unarjjrt*. Further suppose that many of our 
programs that use binary_trtt'i need to examine all die leaves of a tree in left to right order. If 
we are given operations to fetch the left and right subtrees of a tree, we can look at the haves 
in the desired order by keeping a stack of trees. A loop to do this might took like (in CLU) 



- ■ * «- — "*'* ''^S^^MS'^^f^^^¥^^^^. ! ^ ,f ^ 



-^*>- ; »- J , >c-^-35^<* ; -' 
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t: tree .:- trtt ofinttrtst; 
st: treestack :- treestackScreate (); 
more bool :- true 
while more do ' ' 
if t is a leaf 

then 

loop body 

if treestackSempty (st) 

then more :« false; 

else t :- treestack$pop (it); 

end; 
else _ ; 4- 

treestackSposh (st. rlftt subiru oft); 
. .... tvttftxubtr4*tfpy ' ' 

end; 
end; ; '"' '■':' ■ l " 

Thus, the stack of trees is used to remember the. all 
generated. Writing this code out for every loop is 

details, if the type Hnaryjtrtt offered an iterator called Imms, we could write the above loop 

this way:' 

for I: leaf in binary jrortleaves <l) do 
loop body 
ciio; 

The vatrlaibie^ to called, a tet> >wffM< a^ t to jo^tiv^^^jaa^^a^Mf^. VK 

The for loop is more to the potot^ajd^ the while loop. 

In short, iterators provide better abstraction. Iterator* can abo be more efficient than loops 
written wit, because they can be operations of Jj ,c*^^..^^iro. amu. ,ip the 
representation of objects of the type. f The definition of the ^tor /w«i might took Uke this. 




^laavps of which have not been 
tP*nro«,ar»d r«Mes on many 
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leaves - iter (b: binaryjree) yields ftaaf); 
if »<*«/#»/ 

then yield (b); 
elM 

for Is leaf in btnsryjreetteave* fin* ittttrte •/ W do 
yJeW(l); 
end; 
for khan* fat fc^ry jieef hm»es hfyn* sadfiof */ft do 
yield <»; 
end; ' 
end; 
end leaves; 

The recursive iterator makes our intent mora obvious, and shinw a symm e try to tlte generation 
algorithm that was obscured In the white tons.. There laa M«»ilbim; that the recursive version 
is less efficient than the iterative version, hot ft H not immediateh; obvious, end may depend 
upon Implementation details. 

Let us turn -# the semsmtta undi i lying IbUU. iterators. The basic actions involved in 
ustrig an itemtor fn a fo* tftaj are: 

<1> the for loop c*tti the iterator, 

<2> the iterator yfffcfi objects to the bodf of theferhaspv 

(3) the loop body is executed witn the loop variables set to the objects yielded by the 
. iterator; 

(4) the iterator is usumtd, whereupon It either tomhwes to yletd items, or 
<3> the Iterator rrtitritj, termintttnf the bop. 

Note that the loop body h executed once per yield, as the example would seem to imply. Abo, 
the iterator tt always returned Just after its hist yield statement, with a* local variables intact. 
Thus iterators are a form of coroutine. General eorouUn e i reootre one stack per coroutine to 
run. but iterators are sufficiently restricted that they can be Imp l emented with a single stack. 
(Iterators run in a single stack because of the oarncolar patsern of resuming they ute> Let us 
detail the transf ormatieni made to the stock for each of the baste actions listed above. 
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U) Iterator -tall-,- the arguments are passed and a new frame Is setup for the iterator. Just 
as in a procedure call; 

(2) Yield - the loop variables, which are created at this point unless they are of fixed size, 
are set to the objects being yielded, the iterator's resume address and frame pointer are 
pushed on the slack, and the ftM^ loop body is eniiTed with the environment relet to 
that of the iteratorVwHer; KMUct that thto is startler to a ca« even though yielding is 
semantically the Mune a» reto»mlf»g>; 

(3) Loop body ^ the loop body executes nornwHy, pwshlng any temporary information on 
the top of the stock, beyond the iterator'* frame, 

(4) Resume - the stack |s popped back down to the iterator's frame, and execution of the 
iterator begins again at Its resume address, with its environment restored; 

(5) Iterator return - the iterator return* to its alter; execution continues after the for loop. 

Thus, a yield is a kind of call, and a resume is a kind of return; both are a special case of 

coroutine resumption. -' 

As the example demonstrates, iterators may contain for loops, even ones that call the 
iterator recursively. This is useful for walking recursive data structures. Although we did not 
show it, it should be clear thaj for loops can, be n^ste^ witb, pq dif f iculty^ 

Another feature we did not mention is that a for loop can be terminated in other ways 
than by the iterator returning. The loop body can" execute a special statement called break, 
which terminates both the body and the iterator, continuing execution after the for loop. The 
body may also execute a return statement, which terminates the body, the iterator, and the 
routine with the for loop, all at once. 

S.I.I. Implementing Iterators for ASBAL 

The description above has been of Iterators as they appear In CLU; here we will see 
what form iterators take in ASBAL. TIrst : ol alt our call mechanism can be trivially extended 
to include calling iterator* Iterator returns are also trivial, being the same as procedure returns. 
Yielding is a little more complicated. Semantkalh/ a yield is like a return. However, it cannot 
be implemented as a return in ASBAL because returning in ASBAL always create new objects; 
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an iterator should be able to generate a sequence of existing objects, such as the elements of an 
array. This suggests that a field statement sfcotrfd pn a bat of expressions, which will be 

evaluated to objects, as is done for selections: 

yietd(«^; 

yield iexpj, txp 2 , .... txp^; 

We also need a yi*Hh clause for tteiator headers (the rest of the teader can take the same form 
as procedure headers), which def me* the order of the kerns and their types. It hi useful for the 
iterator to control whether the objects it yield* wdt be const or rat in the loop body, so the 
yi«W* clause includes that inf orm a t i on at s*dl Her* am tome examples: 

i - iter (const a, te tnt» yleHi feionjt fcjtfr 

or 

i - iter (const f : fob, var b: bar) yields Ivor foobar, const char); 
or even- >■■ ;■».■>■..-■,-■ ..-«■ . -• -■ ,; ;•-..■' • •.<■,•, ■■ 

I - iter (const count hrt) yields 0; 

Now, let us consider the. form of die for loop itself. The general form may as well follow 
CLU's. The only part that need* tt» be different f roa» CUU H die declaration of the 1 loop 
variables; the declaration wiH state whether the loop will use die yielded objects as oonet's or 
var's, Here are some examples: , . . 

for const x: int in ... do ... end for, 
for var x,y: int in ... do ... end for, 
for const x,y» int, var v. beef In ... do ... end for, 

The forms of the break and return st at e m ent s are 
break 

and ■ ' •■■ \ 

.1 

return 
S.I.2. Summary 

We introduced the notion of an iterator as it appears in CLU, and we looked at the 
semantics of CLU iterators to help us design iterators for ASBAL. We tr*en designed a form 
for iterator definitions and for loops hi ASBAL. There wp be more examples of iterator 
definition and use at the end of the chapter. 



:. ^ry&$*?:,^ ■-&*- 
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S.2. Exception Handling 

In our earlier discussion of procedures we omitted one Important aspect of procedural 
abstractions. A procedure, iterator, or selector might notify Its cafter of an unusual or error 
condition. We unify the terms unusual and error in the term exception (or exceptional), after 
Goodenough [Goodenough75]. In this section, we first examine CLXTs exception handling 
mechanism, 1 and then proceed to modify it for ASBAL, in much the same spirit as we did with 
iterators in the previou* section. 

3.2.1. Exception Handling in CLU 

Any procedure or iterator (we say rouHnt tot short) in CLU may signal exceptional 
conditions to its caner: The CLU viewpoint on the meaning of such signals is this: a module 
signals to indicate that it cannot perform its duty as a good abstraction. This might be due to 
an inconsistent state of an object, because of bad arguments, because of a hardware failure, or 
because of a system limitation (eg., out of memory). Of course, it may lew odiously indicate an 
unusual but predictable situation, such as endygJUe, The simplest semantic view of what a 
procedure does when it signals an exception is that it returns a different and distinguishable 
kind of object to its caller. Each exception the procedure might want to signal can be given a 
different name, and a list of objects can be sent along with the signal to further describe the 
condition. 

The procedure's caller has the option of handling exceptions signalled by the 
procedure. If the caller has a handler for the exception, then it U executed, and execution 
continues after the statement to which the handler was attached. Jf the caller does not have a 
handler for the exception, then the caller signaU a special exception called failure, sending 
along the string 



1. We note that this aspect of CLU has been subject to change, so do not consider what w* say 
here to be definitive about CLU. However, Western* of the mechanism is expected to remain 
the same. We trust that any further work with ASBAL would adopt any improvements made 
by the designers of CLU. 
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"uncaught exception: namt-of_jrrigtiuU-.exc4ptt»n" 1 

Here is the format of a statement with a handler Mock attacked: 

stattment; 
except 

when txttptloKJMm^ hondUry 
when exctpttoTL-namp HantU^i 

when txupUmuwm % ; htmMtr n ; 
end; 

A handler block handles only exceptions arising from invotatkan to the statement to whkh it 
is attached.. Handier blocks may be nested, since a statement with a handler block is considered 
to be a statement. If more than one handler is available for an exception when handler blocks 
are nested, the innermost one takes precedence. 

This exception handling mechanism is different fiom that of PL/ Ul*M>03 la several 
ways: 

(1) Handlers are textualrj associated with blocks of cede, rather than being enabled by 
something trfce an on statement. 

(2) Executing a signet statement alwys exits the current procedure, and it may not be 
resumed, 

(3) The entire caH stack is not searched for active handlers; rather, a procedure must be 
prepared to handle all signals that might come from any procedures ft calls directly. 2 

Having handlers stattcaRy associated with blocks of code was chosen over dynamic 
mechanisms because it is cheaper and caster to Jmpl i lest confusing, and sufficient in all 
cases SignaHmg always exits the current procedure because this is the only thing consistent 
with CLU's viewpoint that a signal indicates an mabUtty to continue to perform as asked. 



1. To help in debugging, if a procedure does not handle fttiurt, then St signals /«tf«r#, sending 
the same string as it received, instead of "imrinfflir inrapllm faltiia* 

2. It is safe not to handle an exception only when It ^ certate limtlhi mvocatkm in Question 
will not raise that exception, For exam hi W *>* fJatn « yrffomtm H •iueaeensbhrnbt 
to handle the exception for division by iero. 
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Thus a procedure is saying "I give up!" when it signals. 

Let us go through an example. Suppose we have a type qutut with an operation 

called next which returns the member at the front of the queue and removes it at the same 

time. Clearly, queuetnext cannot work when applied to an empty queue. 1 Let us say queueSnext 

can signal an exception empty. The definition of qutuetnext mi^ht knk like (in CLU) 

next - proc (q: queue) returns (element) signals (empty); 
If q is emptf then signal empty; end; 
ftxufiq; 

return iold head of q); 
end next; 

Thus, we see that a signal* clause Is required in the procedure header. Here are some 

examples of such clauses: 

signals (foo, bar (int)) 
signals (btetch (Int, Int, bool)) 

The first one states that the procedure can signal two exception*: /», with no objects, and bar 
with an integer. (Factoring is disallowed here because It leads to ambiguity.) To send objects 
along with a signal, they are listed as in the yield statement 

signal bar (7); 

•Ignaffoo (i ♦ 6, i * Z, x > 5); 

A call of queuetnext and handling of the exception empty might look like this (again in CLU): 
begin 

x :- queueSnext (q); 

end; 
except 

when foo: ...; 

when empty: ...; 

when bar: ...; 

e 1°"l 



1. We are not considering parallel processing situations where such a request might hang until 
another process puts an item into the queue.. 
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If a signal sends objects, the handler declares variables by which to name these ob^cts. 1 The 
following example #how$ how thlik dene, 
begin 

end; 
except 

when ohJoo<xj:Jm, i:be«4):«^e/4«ua#r; 

■end; 

In CLU. the semantics of sending objects with a signal is the «me as tftet Of returning objects. 
If an iterator signals, the fer toop that invoked it is imniNiaml, and a handler 
executed just as if a procedure invocation had si g nal le d . Natttraltv, the locus of the signal is 

>|M " M -Tf" trr itrrttrrf tf thr tup ttf thr fnr itarrnwm : ToV mamptc 
for ... in iterate ix) do 

end; 
except 

wfcen4ter*te^mlltfi^:4m»4fcn 

end; ■ 

If a- signal statement is executed in the for loop body, the body, the iterator, and the routine 
containing the for loop are terminated ail at once. flWKim&mm bdsfNrent from the body's 
catching an exception, as in 
for ..."do 

statement; 
except 

when oh_focc ...; 

end; 

end; 

If oKjoo is signalled by some routine invoked in mttmmt, then the handler will be executed 



1. Actually, the handier may choose to ignore the objects entirely; the ambstsous reader can 
peruse the syntax m the appendix. 
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and the execution of the body will continue Assuming we have shown all handlers, if ohjoar 
is signalled by some routine called in statement, the body and the iterator will be exited, and a 
more global handler executed (if there is one). 

3.2.2. Exception Handling in ASBAL 

To transfer CLU's exception handling features to ASBAL, we need forms and 
semantics for signals clauses of routines' headers, signal statements, and handlers. Signalling is 
basically like returning, but the items sent along with the signal will probably not be handled 
the same way as return variables. For one thing, it is wasteful to allocate space for objects that 
might only be signalled once in a white. Another point is that these objects are always the 
initial values of some new variables and constants: those declared for the handler of the signal. 
The best approach to sending the objects appears to be to leave them on the top of the stack. 

Unfortunately, the space at the top of the stack overlaps with the variables of the 
signalling routine. The objects will have to be computed first and then copied to that area. 
Unlike the case of returning, we will probably be willing to pay the price of copying items 
down onto the top of the caller's frame when they are to be signalled, since exceptions are 
generally rare compared to returns. This leads us to a signal statement like CLU's, except that 
ours always creates new objects, just as our returns do. Thus we writer 

signal foo (10, b(3»; 

signal bar; 

The signals clause in procedure and iterator headers gives a Hst of types, with no names, just 
as in CLU: 

signals (foo, bar (lilt, arraytbooll)) 

signals (bietch (int. int, boot)) 
Once the calling routine has the signalled objects at the top of the stack, the transfer to the 
handler is semantically a jump, but objects are sent to plug into the handler's variables. The 
handler's variable list will take the same form as that of a procedure header's argument list 
part. For example: 



04 



except whmtxxricomii. int, b: b*H rare cfcei*: ... 
end* ■.., 
Thus the sequence of acttoro for r signal m ASBAL it« hjlUimi 



<D the expression* in the signal statement (tf «yy) are* compuiauf h^ing' objects in 
temporary variable* of the signalkng pTOBedure; 

(2) a run-time system routine examines i data ^^^^^t^fm^lm, of the calling 
routine, 

(3) it proceed* to adjust the stack ■. ^m^J^ ^m^1^M 'ff^^ < *»^ 
< using, bit-copies); then 

<4» it make* the haiidieitevBrtai^^^ 



This is a bit complex, but .the rttn^mie system ro^ it is not 

too painful. The infomatt^that im« Be^^ jftwleally It 

consist* of which range of addfeoer nTthV|ira^^ bJ**, s , !| tt 

of the exceptions hand**? am* the addm*. t^m^fi^jf^^ )h* ^m^mim |. 
ordered' on^ly, th* ruiwime routine need^f^ a 

table. The copying of ofcjn doe* not lead, to an^^^mj^ «rtst* at 

fixed offset slots for tlnr objects, or space at a fixed offset m» saved fox a pointer The 
object* that really go on top of the stack can be put Mem in anyfOtder since the. are referred 
to through pointer*, and popped off all -at once besaum they attrnnm tb^ Thus, 

there are no ov*r*»*ieiming implerneiHatton probJim* for nrjuipml ^IL., I m.^ 

mechanism; though it dowof ooarse hKursoim overhead. 



1. This list *****»^m"? ^^ 

inwpspwje piosoamiy i ln tta i il Poi< i wi llalMMT l i i ntt s W i iwn l j ffifln ii E i#i oomteT in a 
"*^ fm ^J"P™"^**»^+P* ™*»<»* V*— H " u » \ ee 7uaeaaa^ /o» the 



handler variable ) 
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3.2.3. Summary 

We have examined CLU's exception handling mechanism in detail. Based on this 
examination, we designed parts of ASBAL to perform the same function: the structured 
notification and handling If exception*. Fortunately, few changes were needed in the 
mechaWfstif borrowed from CLU, and llttte addlttonal mechanism was required. Again we feel 
we Have been successful in trinsf erring a good feature from &U to A^Sal! 1 * 

3.3. An Example • Sorted Bags of Strings 

This section present* another data type definition: a sorted bag of strings. This data 
type might be used for computing ihe frequency of o c cur rence of different words in a sample 
of text, and printing them out in aj ph ab etio sr order. <(Our presentatten is based on the 
example in [Lisju>vm Here is a detcrttrtkm >6t the efwratiofu: 

create: proctypeO returns<bag); 
(create a new empty bag) 

insert: proctypefvar bag, const strtngtgd ill) 

(insert the string into the bag; signal fuf if there is no more room) 

count: proctypefconst bag) returnsdnt) 

(total number of items in the bag, counting repeUUons) 

size: proctypeCconst bag) retarnsdat) 

(total number of distinct items in t be bag, U- not counting repetitions) 

increasing: itertype(const bag) y idds<const s^ringC^O], inf) 

(generate each distinct suing ag, with its repetition count, in 

alphabetical order) 

The type string in ASBAL is a sequence of characters. Of course, string variables must put a 
limit on the maximum s siie string they can store, fnat is the reason for the parameter *2ff to 
the string types above (the V m 'stringC^OI* #M be explained in the next chapter.) A string Is 
different from an array of characters' In that JU contents cannot be changed, i.e., strings are 
immutable. Strings are whole values even though their individual characters can be accessed. 
The usual operations on strings, such as substring and index, are provided in ASBAL. A frill 
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list of string operations it in Appendix II. 

3.3.1. The Representation 

The . representation we will use for bag* it, a binary tree. Each node will contain a 

string with a count of the number of times that string ha* been inserted m tb* bag. All nodes 

to left of a given node contain strings which alphabetically peecede the string anarlated with 

the given node. Of course we need to keep* caunt^^ tree in 

order to compute size and count efficiently. This ^op level rep" is then tomething like this: 

record [count: in t, 
size: int; 
t: tree! 

We will ma4ntatn the tree in an array, using array ittdeinM a* ^potntere'' to the subtrees in the 

node*, (We must put » limit on the nombw of diatlnct Hums in a bag. We wittme 500 in this 

example.) This adds stuff to the rep type. (To he realty i h i t w suo u ! it we wo u ld define the tree 

part as- another type, but we desired to keep theewsnyh ilwei:VTh»iet«Bltts: 

rep - record [count: int, 
site: Int, 
root mbranch, 
tree anlj 

an - array [node, I, 5001; 

node - record fs: strtog{;20], 

left: mbranch, 

right: mbranch* 
number; intJ; 

mbranch - oneof I empty: null, 
branch: ietl. 

The type mbranch is short for "maybe branch": it is eitrw wiiplf , or deslgiifttei a branch, by an 
index into ther array. A oneof type is a discriminated union, somewhat Hke the variant records 
of Pascal. [WirthTH. A oneof object is a W$ {one of the flit* names) along with an object of 
the corresponding type. (There are operations that convert an object of some type to a oneof 
object with an appropriate tag. They and the tagcase s UUm e nt wHl be presented bctow) 
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Allocating space for a oneof variable is euy K >Ht ajtaate the ma*mHiro of the sixes of the 
various possible types in its fields, plus room for the tag. 

3S.2. The Operations 

Let us start with the create op e ratio n for ba»> We must set all the counts to 0, and 
initialize the array. 



•'s» 



create - proc returns (b: cvt); *' 

none: mbranch :- mbranch.make_empty (nuH); 

n: node :- nodetU: "", ~ . u m v ' <* ■■ ■ 

left: none, J 

right: none 
■■'■■■ nwm b U. O); •>'• ^ ' *■ 

b :- repSfcount: 0, j * 

site 0, 
root: none, 

tree: an$f III (hi I, MOW; 
end create; 

The "" means the empty (or null) string. The crm* operation shows how to make a oneof 
value from a non-tagged value of the right type u« d» frmMb^ o ps rM lo n , hi this case the 
make_empty operation. (This operation calls the copy operation of thliyp^J 

insert - proc(vai "b: cvt, const JM* NM^ J*P * Mft»1».i..: 
b.root :- insert! (b, s, bj-bot) except when fuH: signal full; end; 
end insert; v - ; - : --m ^^ ..- ; -'<'■ bw%*,\ w j^,-* ~ : : v 

insert! - proc (var b: rep. const s: stringCjJWJ, root: mbranch) returns (m: mbranch) signal* (full! 

: .t*f&m-.tm*im:.-..r ;. -f-:-:^"- i, ¥t"'^-- .-■A:-G»r*« k'-*-iU"Uv >' -■=>..; o.<?. -v.-» 

tag empty: 

m :« addjiode (b, s); 
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tag branch (const i: int): 
m :» root; 

•■'Wtmtv&'h — b.treeWde • 

Iff -'114 •,;..• .-, i .-^»- ..•■••■;■ 

tttcn 

n jnmiber :« n.number + 1; 
bceunt -9» bxount ♦ 1; 
etseif s < n.s 

th«» n tef 1 1- h M Wt> <^ vnrte T 0; '■>. 
el« n.rtgbt :- miertl (b, *, iwlgbt); 
end If; 
end with; 
end tagcase, 

except when full: signal fuH; end; 
end insertl; 

add_node - proc (v«r b: rep, const a strtngtaQs) safini (br: rebranch) signals (full); 
if b-stze - 50o then signal lot; end «; 
b.&ize :- b.size ♦ fc 
b.cotmt :- b-count + 1; 

none: mbranch :- mbr«nch$nuke_«nptf (»i»; 
b.tree<bjJie> :- nodetd: s, 

number I, 

left; ->,.. none; 

right: none}; 

-■br**d»nit*c1l»lidMh^ 
end 



This operation illustrates the use of internal procedures (that is, procedures net exported by a 
cluster); it also demonstrate* hoy to os« th» Ugrase s ti s i wi unL to rt l ii rHn a, h ' with a oneof 
object. Each case shirts with "tag tof and allows a name to be given t»thw defect m that the 
name has the discriminated type. This M ttmmtf way an objsct.nt a enoaf can be mutated. 
We abo see a refuse of exception handling and signalling, rthsugn wmmm^ftuiKf one. 
The count and size operati o n s are easy to write: 
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count - proc (b: cvt) returns (c lot); 
c :- b.count; 
end count; 

size - proc (b: cvt) returns (s: int); 
s :- bsiw, 
end size, 

The last operation to write is the iterator incrtcUng: 

increasing - iter (const b: cvt) yields (const string, int); 
for const s: string, i: int in increasingl (b, b.root) do 

end for; 
end increasing; 

increasingl - Iter (const b: rep, bn mbrancn) yields (const string, int); 
tagcasebr in 
tag empty: 
tag branch (i: int): 

with const node -- b.tree(i) do 

for const s: string, J: hit In increasingl. (fe, node.teft) do 
yield (s,j); 
end for; 
yield (nodes, nodcnumber); ( 

for const s: string, J: int In increasingl (b, node.right) do 
yield (s. J); 
end for; 
end with; 
end tagcase; 
end increasingl; 

Again we see a recursive internal operation and use of the tagcase statement. At the top level 
our entire type definition looks like this: 
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bag • cluster i« create, Insert, count, size, inamsing; 
rep • .„ ; 



create - ... ; 






insert - ... ; 






insertl • ... ; 






. add_node « ... ; 






count • ... ; 






site • ... ; 






increase - ... ; 
iricreastngl » ... ; 
end bag; 






Here are some example uses of the bag abstractson « 


M ■*#* UUJPJIU> 


b: bag :• bag$create 0; 




• sc'f fens 


bagfinsert <b, "a str^g^ except when fu* ^x^ ohJ»**nd; .. 


avg: tut :- bagtcoont (W / 


bagtstttfb); 


Hi '.-■.{ "' 


n: <«* :- bagtcount (b>; 
for const *: string, 1: hit hi 

end for, 


i b«gtincre»s*ng Cb) do 


»•: 



division): 



S.4. Summary ■'"'"■ 

This chapter has presented Iterators and exception handling for ASBAL. These two 

features were borrowed with Hole change from CLU, and tlie is^cr a» A*BAL was uutte 

successful. Alt the central features of ASBAL have now boat pisinnul, ininhn matotr from 

■•*» with alnJrMM fc «***«,* dor objr* lmrta,U.ll,, of ^We. Th. ne.t two 



chapters consider two additions to the l an gua ge . The first h asiaiiisoji (isUuii of abstracttons. 



We wt« explore adding CLU* parameter mechanism to ASBAL, and wM end up augmenting 
it with an original feature for handling types wish objsets of dynamical* rarytog sire The 
fohowmg chapter investigates adding limned Hn piiiiaasing casMsMMas to the language. The 
features designed «*aw the o o nsu o oto n of gen e ral gnu* structures without garbogt coHectton 

- In the stack. 
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4. Parameters 

This chapter presents the ASBAL mechanism fc* parameterizing abstractions. We 
begin with an examination .of parameters in QLU. W* then borrow and extend CLU's 
mechanism, modifying it to suit our needs. The major extension made i$ for parameters 
relating to the sizes of objects in ASBAL. We have several goal* in extending CLU's 
mechanism for ASBAL: 

(1) to make programs as independent of the sites of their data objects a* possible, and to 
allow sizes to be determined at run-time, 

(2) to relieve the programmer of the burden of keeping track of the sizes of variables, and 
to transfer this burden to the compiler and run-time system; but, 

(3) to allow the programmer ultimate control over the sizes of variables. 

After presenting our parameter mechanism, we give an extended example using it. We close 
the chapter with a discussion of possible Implementation techniques. 

4.1. Parameters in CLU 

Here we discuss the parameter mechanism used in CLU. We start with the simplest 
and most strongly motivated case - parameters to clusters. We present a full example of a 
parameterized cluster, and then move on to parameterizing other abstractions. 

4.1.1. Parameters to Type Definitions 

Let us say we have written a cluster to implement queues of Integers. A while later we 
find a need for queues of strings, so we write a new cluster to Implement them, borrowing from 
the previous cluster. Some more time passes, and we find we need queues of customers for a 
simulation program, so we again adapt the queue-of-integers cluster. This copying and 
modification could go on forever. What is worse, If some subtle bug is fewnd in the original 
cluster, a lot of effort is necessary to find and correct »ll the other clutters that copied its code. 

One might imagine using a fancy text editor or macro processor to help in this 
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correction and updating process. Ifow e »et, we am de much belter u? we ; «*e dke idea. of am 
abstraction generator: a parameterized modute predating one aeatnaadanaawaoi of parameters. 
For example, we would like to write a defmtdon of uuaues oung a dojunn/ noose for the tppe, 
' and to anew auj type 1o te^ilted In amj te e^ dk hind ^af 'ajuoae iiibuo sd. "this groups the 
mvormatien tot air cuuues or Queues ssnumir,, m /UBUujsjes affect an wwant, est a 

■ ._ ^^A^^AkS^ iu^HUaa^riul 'Oa*J^a4 : AO^au1 ^'vl^id^ ^g^t -^je^kjL^^ Li^odnMUMt' om '— ^Jd^^d — •" j-, dWa> 

yniCTwfaf, suftet 'life oobrocquhs gunomea are tspes. m uauuu uuner uauKpuHn me s e ma i it iq 
with an example <*n CLUJ: 

queue - duster It type] Is create, una, dea, empty; 

rep ■ arrayCt}; 

*»ate<»-ntuefH«tB*«£fe^ :'■■-'•■ 
i etojo (auafaumQ); ■ 
end create; . 

enq - proc (f: crt, X: t); 
reptaddh (q, x>; 



dee, - pruc % c*tl returns (*) signals (empty); 
if reptsixe Co) - 
Huso signal empty, 
else muru <fep$temt(o>); 

■ . do*, ■ - 
enddeq; 

empty f.pfec^:^Ot*imi*s time*; ... 
mtura (rep$stie(e> - Oh 
end empty; 

end queue; 



The first thing to notice is the Tt: tjpeT after ehuiet, which stgmThB nut* ftutu takes a single 
parameter, called t, and that the actual parameter 1 most be a tape, Tuoo, far «f«rv type yba, 
say) there exists a uueue of that type {written fusudjltall. Even ausauCyMiidCyif rwrfindl] Is 



...-.^. ■ i ne fcrm oqme< asm cosonsstaa mrvsw. lueteuums mundane ene^snuMoaaanro 
template {formal*, and an msuinos of tt <^cfus/). 



" ^gJ^Hwfc 
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legal because queuellnt) is a type, so It is a legal parameter to fueut, etc The representation is 
chosen to be prrayM - this demonstrates tbet ri» ittterpeeltdyas if it were an actual type 
specification 1 iniMe the cluster definition. The c r*«/« epe fats o u ismpiy returns aw empty array 
(representing an empty queue). The #rtf o e eraU o n adds a new i hfent to the high end of the 
array. Notice that /by Itself U a vaUd type i p tr j ftn i H o n in Hie header of the <ny operation. It 
is also legal to decbu:e vajlal^ fe b^^^ this to drive home 

the pqinf that t-ttdty U taken jo ha a t?^ speotf icattoa wwhin the definition of yaw*. The 
<ieq operation is symmetrical to tnq, except that* max sigaai cat**;, indicating that its caller 
tried to remove an element from an empty queue. The mpl) iMienilim Ji Jim ■ un to see if a 
queue has no members. . : —. - ^-.s 1*-" :: '-' - s ' : * 4 ■•■'j.-- 

4.1.2. Restrictions 

In order to demonstrate further features, we win add some new operations to the fu*u* 

cluster. One nice operation to have is copy. We would like copy to call tScopy on each element 

of the queue. Of course, this means that we can only copy puudtl If t has a copy operation 

(which it need not have). For this reason ustricOens wei to CLU. A restriction defines 

a set of types possessing certain operations with particular fwcttonatttles. Restrictions are used 

to limit the legal actual type parameters, and they insure that each, actual type parameter has 

the specified operations. Let us look at qtututccpj for an example: 

copy - proc (q: cvt) returns (cvt); 

where t has copy: prectypeCt) retunurft) end; 
return (rep$copy(q»; 
end copy; 

The call of arrayCrlScoft (implicit in rep***?) results in caHs of rtcopy; since arrayMSco^v 
requires a copy operation of t, we must require that operation of our caller. Restrictions 
complicate type cheeking, but are necessary. The where dame can also require a parameter to 
have several operations, and can put restrictions on any number of type parameter.. The 
keywords proctype, Mertype, and tatty peace used to dec*^ p>i»edu<», iterator, and selector 



1. A type specification is the syntactic description of a type 
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types. (The keywords proe, iter, and selector are not used for thli purpose because syntactic 
etnbigukies result) 

The above examphrputs a restriction en a iingk ^«iiru|W i attow . If /does not have a 
€opf operation then att the other eertrattons of fKMMCfi can br ttsed - JO* not «K*tMCrl$a>/>y. In 
some casts- it is desrraWe to pat a restrictkvr oa aft the operation* For example, consider 
wctending our sorted twy sa^ractton oTdte pie* h*» chapter to a ^ That is, we 

define a type generator jorfdwArf, whteh c»n be hi lUiitl a tad to produce sorted hags' of any 
ordered type In terms of opemtaaas, th#iapoe*a*Bteie^ 
and an equal (g^uai) apaaataamf Such a restrietie* to stated Mkethtot 



sorted J>^ «■ chwiar ftt type3 to .» ; '.- 

where t has It, equal: p r oc typ e tt ^) retnrns<boeJ> end; 

end sorted _bag; 

We can still put further restrictions on the type parameter within individual operations if 
needed. - Thus* e eapy operatton for the sotted laaf cfc^ a copy 

operation. - 

4.|.9' Parametm to Procedure* and Iterators 

Just as clusters can be parameterized, so can procedures and iterators. Consider a 
bubble sort routine that takes an array of any appr o priat e type and sorts it. The same 
reasoning that lead to chuter parameters to effective here. Hem to the procedure header for the 

■.■■•■■'■.■■ -i '■' :'■•■?;■'; -. -'■""S .(J -- '10.:."'' 

sort routine 



1. We^would rea% hke to lay that ft and qual order the objects of type t, but all we can 
require in a reitrkttao to U>ee an e c t f ii w ( ta sii a ii (| N a iaralhi, t h e *aat th a i ft orders the objects 
would be included in the specif kattoro of the sorted bag abstraction, but we do not expect a 
compiler to check such specifications, and so do not mdude them ta the source text 



^W^^^^^^W^^^f^^^^^^^^^-'^mf 
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sort - proc It: type] (a: at); 

where t Has equal, k: proctype<U> retenw(beol> end; 

••"■' end sort; ;ft "*' 

Operations of a type may be parameteriwd Jisj w ref«l»r routims can; this leads to the 
following general form for o^ 
<>A«-nei»wr.jhir«a^ 

4.1.4. Other Kinds of Parameters * 

In CLU, most compite-time constant* are allowed a» parameters. This includes 
integers, characters, strings, reals, boo le aws, and nulte. Bkta^aT these an? very useful (there Is 
only one value of type anH, » awli » useless as a param et er type). Every distinct set of 
parameters to a parameterized abstraction re*** to* dbtMCt ai»sfracrton. This rneans that 
flru«tt«tint] is different from fu/urfboei], etc Also, * we ate gtveri the definition 

. . foo - cluster tx, y: iat] .. ; ■■. 
then /ooC/,2) is different from f«£2,21 In Hke fashion, different sets of parameters to 
procedures and itetf tees prod tw« diffei^t ptoc e dw e e and- iterators. : 

There is a goaMhat type checktef «e possiote at ccenptle-tlme, which requires 
instantiation to be possible #t compihvtime. Th e rtf e ea, pa wm e iai s may net be computed at 
run-time. However, it turn* out that even ># alt pemm d mi ' are co mpi le ti me knowable, 
instantiation is not ajway* possible at ^ompue^ime. Ttrts d tff h u sty will be discussed lit the 
section on imptemeouttoa Still, run-time mmrimen erareai tons ere not allowed- as parameters. 

4.2. Parameters for ASBAL 

ASBAL can borrow alt of CLlf I parameter mechanism with no significant changes. 
However, even though that mechanism wcrts f me, ft u not convenient for what will be the. 
most widespread use otp^ram^ 

size parameters to be computed at run-time, this extension can be made without too much 
trouble, but it is hot sufficient Using CLtli rnechanism for' sixes win still be Inconvenient 
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because every size must be specified explicitly, and each set of size parameters will result in a 
distinct type. This results hi a distinct set of cluster operatiem iW each size (although most of 
the physical code for the operations can be shared among a* iratane* of the type generator). 
The major difficulty is that binary (and higher order) operations on objKtzof different sizes 
become hard to express, because a duster may convert entr objects of its own specific type to 
and from the representation. Therefore, mere Is no way to access the representations of objects 
of different sizes simuttaneousty, because objects of different sizes are of different types. 

With the proliferation of parameters, expressions became pate complicated. Consider 
strings as an example. We could not write 

S ;- s II t; 
(The U' is a sugar for concat) We would be forced to say 

s :- string »003Mp^r^iail0ntf rrawetrMili,^ 
to get the types to match if s had size 100 end f had aim ». Just imag ine how obscure this 
statement would look if wrWeoeut Hke theooeaborr 

s:-s«rtr4ng$»ubstrt^i,,j)lstri«f»restttj,#; 
Of course it is possible to extend the notation for Infix oaeeamrs <e^^ K»e^03), but the 
information stiU obscure* thttomputatlon. 

Having each set of •!« parameters define a efferent type fee procedure, eteJ separates 
types too finely, F4ri|«f aHV ft ,*miMtoM^tfMmam-W*im*'# *»% types come In a 
variety of sizes, in. many cases iof mue ^artcrita Ite^ ftxed sitm <beeause they tot ios pond to 
storage allocated in the .«taeb>.> tbjtcts art cance p toawy of uitfauoded the. for example, there 
are stringsof any length gweter than er eaoal to zero, bee i» net pert of me imceptuat type 
of objects but size mfwmatien most s o rnrt^^ variable* 

If we require every abstraction to be bounded, we are putting an artificial restriction on the 
abstractions just to make the imp le m e nt ation work out. One way to resolve this conflict is to 
consider objects to be unbounded, and variablet to b« imperfea owdeb of the objects they 
contain. This leads to attributing sUe t>ow^ variables 

cannot hold all objects of their type, but enb; the oem that will m in *h« variable. 

In sum, size wilt be declared only for variables. We findibat the most con venient way 
to state the size information is as part of the type spe^icatioM <typcspeo) for variables. Our 
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task is to design convenient syntactic forms for expressing size information where it is 
appropriate, and to allow such Information to be omitted where it is not necessary. The exact 
technique is to introduce a new class of parameters to types, rt« puramtttrs. These parameters 
are distinguished from CLU-styte parameters (which we call rtgulcr paxam ttrs) by being listed 
after a V in the parameter list Slie parameters are used only with types; routines take only 
regular parameters. Abo, size parameters are always integers; no other typef seem useful 
enough to justify the additional mechanism their incorporation would require. 

Two examples of size parameters have already beert used in previous chapters. Array 
takes two size parameters, indicating the minirmim tower bound and max iroure upper bound of 
objects storable in an array variable; string takes one jdze parameter, indicating the maximum 
length object a string variable can hold. Arrays and strings are the only baste types of varying 
size; all other types of varying size incorporate them in their representation, although possibly 
through many levels of data abstraction. 1 The irapleirterrtation* of both arrays and strings 
insure that object* too large for a variable pf their type to bold are not assigned to the 
variable: Attempts to make such illegal assignments cause an exception, failurti'txxriable 
over/low'), to be signalled. Furthermore, the inipJeroentation of array* insures that the objects 
in array variables are not grown beyond the limits of their containing variables; if such an 
attempt is made, the variable overflow exception is signalled. To make such exceptions 
avoidable, we will provide a mechanism for querying the size parameters of a variable. This 
mechanism can be used to check sizes before assignments or growing operations. 2 

4.3. The Size Parameter Mechanism 

Having introduced some of the basic concepts and features of size parameters, we now 
go into detail about their use. This is more easily done by going through the syntactic forms 
used for specifying size in typespecs, and the restrictions Imposed on which forms may be used 
with typespecs in different positions. 



1. That arrays and strings are the only sources of objects of different sizes is similar to the fact 
that all mutation is accomplished via records and arrays. 

2. Of course, one can jug attempt the operation and then handle the exception, but it is often 
better style to prevent the exception 
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4.3.1. Size Specifiers 

A j&f Jpettfltr isimspcc) is tlie syntactic form rspro e nU og a size parameter. There 
are three Terms of sttosjhkx, Fftet we have the <wtf ifew^c, whidh llljiilliinn evaluating 

«o«n integer, fit Mine snuattom ih* expression It farther niiid it*, <to bt compile-time 
kfwi^,h«ftcw»tw«%he»riy w i thwt cee i ^uwhl . i w i . m «« W i i "'" " ' ' 

The twxt focm «T stzmpet Is V, and it Is cslbd a>msffp«:.'~ A star Is used as a 
sizespec to indicate that any Vahie it sHewed for that size j annum, "or that the size is 



utwnaterial. Fw exzmpte, a routine may lake a string « an argument without needing to know 
or restrict the sh* of string varitMe m which the strmg obbct happens to he stored. In fact. 



we expect (he tfte ©f snguownts to t* irrelevant*) i 

The other Town of sftmpec is W.mhtnldM an identifto. 1 Thase stsnspecs are called 
T-$ltespeti. The ?-*i»jpec form fe eeuivafant to V, exeapt that * Mlzeapic permits the size or 
* particular varhmte to he ooeried. for example, a procedure p may he written to take one 
argawwm, «n *rra?. To he flexible, p will accept an array of any size, out 'it must know the 
slx«se as mK to csAtsetn overflew mgnrwmg the anay. flie code for p might look ttke 

p - proc f»«r a; a way tmt; ?tow, ftrtgM); 

if x > «?Wgh then ... 

endpv 

The expression afftrg* evafettw to the second size F parameter of the actual argument to p at 
run-time. (The result of tfHgk is not necessarily the ianieai^rn||i^|high^.|he first is 
the size of the variable, and the second is the current Wgh hound of the array object in the 
variable.) ■...?;>;<>■. .s^t 



1. This nourtkjo w»s suggested by the use of 7 in Abtbard CWtd/fSaX 
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4.3.2. The Kinds of Typespecs 

There are three forms of typespecs in ASBAL. The first form is called the variable 

typespec (v-typespec) because it is used mainly In variable declarations. Ail the sizespecs of a 

v-type$p*c Wist be exact sizespecs, so that the actual span required for a variable can be 

computed and allocated. We will detail all place* where each form of typespec is used below. 

Here are examples of v-typespecs: . ■ « 

stringCjlM 

stringt;u(x)+v(x)J 

arrtiyf m, 1, WO) 

arrayCint; 1, 10* J*5) 

arrayCint; f(x), 33 

artaytint; foo(x, y), bar<y, x)+23 

The second form of typespec allows exact or e-sizetpecs to be used, and Is called a 

v^ppptsptt (for variable dr * typesped for short It li used where any size is allowed or size is 

irrefcvw* but where querying is not aflowed. V-trpespec. are a subset of v-typespecs; here 

aee seme v*>typespea that are not V-typespecs: 

stringC*] 
arrajtint; •, 10] 
arrayCint; *, v(x)J 
arrayCint; 1, *) 
arrayCint; u<x), *] 
arrayCint; *, *] 

We allow an abbreviation for typespecs all of whose sizespecs are V: the size 

parameter part of the parameter Hst may be omitted, including the V. Furthermore. If such 

omission result* in X J\ the brackets can be dropped as well. Hence 

arrayCint; *, *] and string!;*] j 

' become 
arrayCint] and string 

respectively. 

The third form of typespec is the most general: any of the three sizespecs may be used 
in it. This form is called the i»ht,ptsp« itx* variaWe, «, or ?ki typespec). V-typespecs are a 
subset of v*?-typespecs (and hence v-typespecs are also a swaeet of veMypespecs); here are 
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*ome v*?-typespecs that awnot v*-*ypespecs: 

strlngt;?ten] 
array tint; 1, ?htgh] 
arraytint; ?tew^*] 
»rray[int; ?tow, ?«gh] 



(There are many more combinations of JfttllUa^ln vtSrtfH&mxiiXMny*) 
4.3.3. How Type Sperfffafctmns are Used 

Now we discuss which form of typespec is used in each syntactic position, and *he 
meaning attached to it in that position. We will do^hjr lapaaraliiy f or dtf ferertt groups of 
syntactic positions. ■■'■'■- 



4,3.3. 1 . Arguments to Routines 



''<'■( i" 



The typespecs foe argumroti to routmes we v*?-^ 
ohjects of any size conveniently. If ^ sire panumter of ajM^nMnl^ptif specked exactly 
(and in this case «miy a aoBfrjla^^ ,„ u u match 

that Of the actual argument exactly. In the case of *- and > sheaf a i, any tiic parameter is 
acceptable. The use ofca?*aiaaapecaHowi^^ 
>example: 

p - proc (var a, to arrayUnt; 1, ?mgh)>; 
end p; 

In this case, both a and * mutt be arrays of integer* with.a Jofwr *ouod of I. 2 Their upper 

bounds are not rotricted,;awtnee^ 

via the expressions <*W andrW&y*AAs anotf^^ 

**ef blowing program^irtii^^ 



1. However, side-effect free expressions mvoWii^ pawneters to routines, and using only 
buttt-ip operations, are - -- " ■ * ■■■ ■ ■ *-*— ut^;^^,,^.,...^.-.^ 



% these boundsare the bound* of *lie*»nkM^ ,**#,. 

3 ^ahould b« thought of as a •peciaTbmary « to <? m selections. 
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p -pfoctt:typeKrar»lrat t ewi»ta2:i^*lfii«U(ov«ffbw<»; 

where t has copy. proctrpefamtt t) eet»rn«U>; 
'vat-ttftrytee,rn%ht;''' 

if tUlib^h- - at«righ<ai» < «tii»t(a» 

then signal overflow; 

end If; " .'°" * 
f or cooct x. t in attetemenuUtS) do 

at$addh(al, x>; 

end for; :? : 
endp; 

The test Hi the If statement U: "Does «/ have enough room for a copy of each element of «£?" 
The element* Heritor for arrays produces each element In the array from the lowest to the 
highest 

4.3.3.2. Return Variables 

Arguments are the rnoft obvious and ^trongtjr moUyated use for size parameters 
because size parameter^ in argurnenu allow sk^le ^ro^ouif* to handle objecu of any size 
conveniently. However, there are also some sttuaUoro where flexibility in the sire of objects 
returned by a procedure Js helpful. For. thU /eason we allow the size parameters of return 
variables to be determhied dynamically; if>ec|fka«y, these size parameters may be computed 
from the arguments to the procedure bring csjwd For e o m p ieh e niib Htty of ASBAL programs, 
we require that any sizj? confutation f» wturnvartebtos i»ot mutate arguments of the 
procedure beings ca^This is doneby pennM^ «it^<P«MC usesof the a r gume n ts in these 
size expressions. 

Consider ; ,a procedure that spends the contents of two arrays together to form a new 

array. If it is known thai the new array wiH never beairlarfod. it it reasonable to create tfce 

smallest possibfe? array that will coptam tM d e airoA result, so *r to avoid any wasted storage. 

Here is the skeleton of tuch a procedure 

q - proc (const al, a2: aint) returns (a* arrayf4swjj4nt$stze(aD»aint$sHe(a2))); 
aint - arrayCint]; 

end q; 
Determining the size of return variables on the fly has some complications, however. 
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Recall that return variables are really spedficattom for vtrtabtas passed In by the caHer. If the 
variable P*^ m M fej*m^ presented 

in Chapter 2 allow for di*»w*iatl^ 

invocation "creating" the temporaries. In fact, that nvxhat* was denned with flexible 
return variables in mind. On the other hand. If the variable pasted in as the return variable is 
not a temporary we rrwy have a conflict of ate. - A t h a<fc l a tut tx d oiw, otten at run-time, to 
compare the size of the variable being passed in with the size dedawd in the procedure header. 
At this juncture we have an option: we may require that the sites match exactly, or Just 
that the variable passed in Is at least as bit; as the one we would get from the return variable 
specification We have chosen to be flexible and allow any variable of sufficient *i*e. We 
delay discussion of the basis for this decision until the entire aiee parameter mechanism has 
been presented. 

Two questions remain: what do we do Jf the size of a return variable Tails the 

run-time check outlined above? Our solution to this problem is to have the invocation being 

attempted Mgnal/o^reClsurt^tf.wwr/tof^ The ether question is: what do we do if a return 

vartabte size compuutton i^n.k? -r~^> | .^ t - n -^ft,-^ w „^ km ||m)|||J toXimotw abwe 

» s*grai/atfurf*"*iw exfruftn signaUetT). 

*ocaose of the nm-Hme checks often required, flexible return variables may be 
enaemive However, «e*ebeve that die common uses *T flexible return variables will be 
handled ^ conipue^me The reason win- co*p|le~t^ often suffice is that most 

♦ypestaking size parameters Have sixes which vary; If a return variable of such a type were 
eofw**«c<crf^^ Therefore, we 

believe it will be more common for the user to specify the size of the variable to be returned by 
passing »* Argument *or perhaps * parameter* » the procedure, rather than having the 
pmcmi»m compute the sUr talf . We believe that the «p r. usod to convey the site 
hiCo*matton maf be cofopambfe at cornptte-ttme oven i that Is, it may be 

possible to perform the checks even if the ske is a parameter or an argument of the procedure 
making the caH. Here is an example: 
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p - proc (const n: int, .,.)...; 

var x: foo(;n]; 

X :-q(n,... ); 

end p; 

q - proc (const i: int, ... ) returns (a: foo£;i)>; 

. end q; 

We grant that it may not be at all easy to design a compiler "smart" enough to perform this sort 
of optimization - we are merely pointing out that the optimization may be possible in many 

cases. 

4.3.3.3. Declarations 

There are two sorts Of declarations: those with initialization and those without. A 
declaration without initialization must use a y-typespec so that storage can be allocated for the 
variable being declared. Any expression evaluating to an integer is allowed for computing the 
size parameters. 

Declarations with initialization are more complicated, because we have the opportunity 
to reduce storage requirements: we can permit the variable to be the exact size returned by the 
procedure being invoked to initialize the Variable. Thus we allow *- and ?-sizespecs In the 
typespecs for declarations with initialization. Any parameter specified by a «- or ?-sizespec 
takes the value computed by the invocation for its return variable: any exact sizespecs in the 
declaration with initialization are kept as is. Therefore, the normal check necessary for flexible 
return variables in assignment may have to be performed in declarations with initialization as 
well; the check can be omitted if all sizespecs are *- or ?-sizespea. Constant definitions follow 
the same scheme as declarations with initialization. 

Here are some examples of declarations and constant definitions: 
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ver n: tut t- JflD; 
v«r a: arraylin*; 1,:«3; 
var b: ar raytta*! »iej « «yI b»tJSntt (0,1, W; 
■ var c: *rfjLit*;l,n*&d :-*ooO; 
const d: airayitotJ-b; 
const e: awaytint; 1,100] -c; 

The low and high bound* of a »m be 1 and m3hoarof a* land SO. 33he«iow bound of the 
array returned by /oo mutt be one, but the high bound rtajy be aay^to i e, , and can be queried by 
writing cM^A. The bound* of d wffl be 1 and flfc fa* Wee *. IBie definition of * wfll fail 
unless c has at most 100 ' ' f 



• j3'- 



•4JJ,#. Representation Types 



The typespec for the representation type (rep type) of a duster must be a v-typespec so 
variables of the type being defined can be aUocased. OeaHy afl ate ^asameters Jo the rep 
typespec must be d ctei mtneb te given all parameters to the absteoet type. However, arbitrary 

expressiomarcaft^ 

of the .abstract type. Ai wtth rebyn Miriabk^. - tba^ fjpaajaja^ nfftit free, 

.because they -.may ;beevajuf|3» r tn^ 

signalled when a rep's size expression 4s evaluated, jmm^stsu rr/rsiatan ttfntitlttT is 
signalled to the creator of Jpt 3r*a^BB|aj|^. v ' ^. ^,^ ? ^ s '.=k """■ ="--" -^ ■ : - " "■ '"■ 

The header for » chiMer with siztiwamettiitajr i thMfiaaa 

The irf, for * > are the names of the sUe rwaaaetttt. Thaw rapsai a rr^nty used ea defining 

the rep type and other ajBja^un^ 

operations as specif fc values. Furthermost, type^. and ..ejuaajsa^ .uaaif : those iawaes «e not 

available to the operations. Tiu> ^ because tfee <veb^ JOJaaJetad rWtth ahe abstract size 

parameter names are not^^uay^ ^ittwt^a^^ eetbaraeaiiadj^ 

sense to use those names m duater opeia^oos. -; r ,, :i ,y 

Let us introduce an example we wUl Uje^Mtwajthaitf lay rlbsnai fcrw of^tjte parameters 
and rep types. Auume for the moment that ASBAL does not have strings, and we need to 
implement them using arrays of characters. Hare is a skeleton of part of the string duster: 
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string - clusteK;len] is ... ; 
rep -»rrsy[ch«r;l, leu]; 
size - proc (const s: c?t) returns (n: int); 
i»> r e ptstat fr); 

end size; ■■ _ . --V '■•.■■<. ■ -S- ' 

end string; -;•>*■ . '=>v.- ■■/ <.■-•■>'■■••• '•'* 

Norice that the sizt operation return j the jize of the pfc>t(U. not the »Ue of the variable. 

Now we come to the question of what a- ,;, and, .. rVsl^tipecs mean, .when written 'in 
typespecs for the abstract type. For exampJe, what doe* #r<n|UJ or strln&M mean? They 
merely mean that those abstract size parameters /***, not bejqg specif led. and tn the case of 
?-sizespecs, that .those .**$*$$ *tze. parwrieten may be queried, e$* *tt If ,x wsredecjared as 
stringhl. In every case where the site of the rep must be known, all abstract size parameters 
will be available, so the rep size parameters cansfae ob iwpw iM and spice allocated. 

The only potential confusion left is the meaning of the typespecs rep and cvt. Rep 
takes the size parameters of the abstract type; the meaning is "the rep typespec obtained from 
giving the abstract type those size parameters". As in CLU, cvt U Just a shorthand for the 
abstract or rep typespec at the interface of a routine, with a conversion applied at the 
appropriate time, down for incoming objects, and up for outgoing ones. Therefore, cvt takes 
the same size parameters as trie abstract and rep typespecs do. Notice that, neither rep nor cvt 
requires statement of regular type parameters; the regular type parameters are implicit in the 
instantiation of the cluster. The conversions up and down have the same semantics and 
implementation as in CLU - they cause tittle or «q nw-tiime action, but are used merely to 
change the compiler's "point of view" on the type of an object 

To illustrate the use of cvt, consider the procedure bdew^ai part of out example string 
cluster: • Jir * K •■-.;* . I 

concat - proc (const si, s2: cvt) returns <s3: cvtf/ep$size<slUrep$slze(s2)]); 
end concat; 

Notice that the arguments (si and s2) have been downed before the computation of the size of 
sS. If we had occasion to create a temporary variable of type rep. hi the string cluster, we 
might write 

var x: rep[;nl ... ; 
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which would be equivalent to 

var x: arrayCchar; 1, n]; 
except that the totter cannot be up'ed. It cannot be v$b& beca involves inversion 

of arbitrary functions in the general case, this is so bursuiplhsOjuw no restrictions on the way 
In which the rep type depends on the abstract type's sin paremeliri; Mbweve r , any arrayEcharl 
can be assigned to a rep variable (provided the sixes match; heme, ittasiftoys possible to up a 
copy of awobject if the types rmtth, ignoring site parametess. ' ' "' " 

ir the sizes of the ttring variablei mpm to the Mncef operation were needed in the 

; c^ratlow procedure bd^ "^' "'' . ""' ■ 

**•-' cohcat ^^%i^^^,WSr^l^^^^' ^^'^^^ '^ iUi 

The kngtfw of j/ and j2 cmrid therTb* ofetami^fy 



4.fA5-. Oth*? Position* in Routine Header* ,• ■ --.: *• r. •.?- o*;< 

There are a few other positions in routine headers that reoutre typespecs. First, there 

are the types of parameters to routines; however, these a tmpea such as int. char. 

boot, and type, which have no size parameters, so there it no problem. The typetpecs for 

objects yielded by an Iterator are v*-typeipecs: a riw is exptkstly given and enforced, or any 

size is allowed, but there is no use for ?-slzespees here The same argum en ts hold for the types 

of objects signalled by routines, and the ef-type m selector limdtii. Here are some examples 

of clauses from routine headers: 

... signals <foo(arrayCint;1^3), bar(strtag» ... 
£• ... yields <sti>?ngV •ii iy rt 'lf afj F^) ... ■ ■■•*-•<■- 

... of string ... ' . ... ., !} ■ ,, r; . ..-.;w 

bletch - proeCx: rati „. 
rah** m itetf trenail... < 
edgar - setectorfftag: booll ... 



-- ■»- >;• , ki,r ■■■■ > «ri-' ' <• - 



».w 
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4.3.3.6. Types of Routines 

■••'■'■ s, t ;■.- ■■'"'.'■■■'' ■ "■ ■ ■■ ■ 

A situation slightly different from routine headers is the expression of typespecs for 
the arguments, etc., in the typespecs of routines (Ia, proctype's, Itertype's, and seltype's). The 
typespecs for routine types should allow full type checking, so typespeo for arguments, returns, 
yields, etc., must all be given. The argument typespecs are v^ypespecs, there being no use for 
?-sizespecs in that position. (A routine accepts either a particular site, or any siie.) Likewise, 
return variables are given v*-trpesoea, hot ectfnputed sites are giVeh at *Vnot expressions: 
only complte-time expressions are tHowed so that as much type checking can be done at 
compile-<ime as possible. Thus the type of strh*gtconcat is written ai 

proctype (const string, string) returns (string} 
which is short for ,;.-;.'--■•. 

fw-oetype (const string!;*}, 9trtofrWntun*Htrt*tftf) 
Yields, signaU. and of- typespecs are til handlsd Just like return variable typespecs. That takes 
care of all the special items in typespecs of routines. Here «* some more example routine 
typespecs: 

proctype<var arrayfbeol^I, const strtngiao]) 
itertype<const arrayCint}) yields (strmgtOfi]) 
seitypeO of ttrmt; rront stffng 

4.3.3.7. Actual Type Parameters 

Now we come to the writing of typespecs for actual type parameters of abstractions, 

e.g., the t in arrayCri. These are always v-typespecs (with one exception), so that variables of 

*.-■;■.<•■-■■ ^/y.M >'••*;:..:• J1>'W .-Osbh r-vn ti in ;*qV"> ■'■■ ''-■■-..*'» ■" : 

the type can be declared. The exception is the type parameter to ptr. The type ptr has to do 
with pointers, which are discussed in the next chapter, however, Jet us explain here how ptr is 
different. The type generator ptr is used for typed pointers, and It takes as a, parameter the 
type of object pointed to. Since the siie of a pointer is independent of the sire of the object 
pointed to, *- and ?-sizespecs are allowed In typespecs used as parameters to ptr. After reading 
Chapter 5 it should be clear why this wiH work. 

Here are some examples of typespecs used as parameters: 
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array [arrayUnt;M@»]} 
recordU, b: str*ng£;20)] 
ptrfa, arr«ytliua!?l%h33 
ptrfa, recerdta, bs string}} 

Please ignore the first parameter to ptr for now; the second p ara meter It the one discussed 
above/' ' ■'■ '* "''"' '; ' 

4.3.3.8. Operation Names 

There is one last position where tjpespecs ace needed) in the names of cluster 

operations. In this positfon ail kind* of typaspatf ere Mhwed* sinot stee parameters are 

completely irrelevant However, it U o>mmon ta wili me sheet feemef^fttsepea in cluster 

operations, omitting the s>» pa£»«eter,je^,^^ a nicer 

appearance, but is not essential. It is aho common to toe a short nam* char Is equated to a 

v*?-typespec; for example, «f for array[d. Alt of tlwm are weal nwmw fm the nmcar operation 

on strings: 

string[£OJ$concat s> v 
s^rtngC;*ifc«wat 
»tringE;?len3$coneat 
stringSconcat 

(This operation also ha* an infix form U*> In clusters, re* ir ah* lee^ a» a type for forming 
operation names. 

4.4. An Example Cluster -Sequences 

The header for the sequence cluster is 

seq - cluster tt: type; nJ is null, addh, addl, concat, remh, reml, trim, 

first, test, fetch, eleinentBt copy, ee^t, tength; 
where t has copy: proctype (const t> retttrsts (t> end; 
Sequences have many of the same operations ** arrays, except that seejusncei are not mutable 
(tfiefr state cannot be changed). 1* is easiest to exphmt how sequences work by presen ting the 
operations a few at a time . But first, the representatiotti 
rep - arrayCt; 1, hi; 
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Thus, sequences will be modelled by array*, ThU is convenient because they are similar in 

many respects. r> 

null « proc returns (s: crtCjOl); 
s :- reptcreate (1); 
end null; 

The array create operation returns an empty array, Its argument specifies the low bound of the 

array object returned, Notice that it to probably not usef u» write 

var x: seqCt] :- seqEtWnulK); 

because all x couM ever hold is the rmptr sequence. < Alt other sequences are too big to fit in x.) 

addh - proc (const s: cvt, e t) returns (new. crtf ;«|**sixe<iM]); 
new :- reptcreate (1); 
for const x: t in repSetemenU (s) do 
rep$addh (new, x); 
end for; 
rep$addh (new, e); 
end addh; 

The addh operation returns a new sequence with one more element at the end than the one 
passed in, therefore the size of the returned object to one bigger than the actual size of the 
argument sequence. (Notice that this is not necessarily the same as y$ ♦ 1\) The tltmtnti 
operation is an iterator that generates the elements of an array in order from the first to the 
last. The addl and emcat operations are simitar to ttddk. 

:'.■<■%■ '.' '>■-- -•,.»'■ • 

addl - proc (const s: crt, e t) returns (new: crt£;rep$size<sMJ>; 
new :- reptcreate (1); 
repSaddh (new, e); 
for const x: t in rep$elements (s) do 

rep$addh. (new, x); 

end for; 
end addl; 
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concat - proc <com* r, i: cvt>retwr»»(nowtCTt {,ieptslao< ri+rep$»iie<s>3); 
new :- rep$create <tf; ^ _, t ,,^ v ^ t 

for const x: t in re p te fci i ten u (r) do 

repSaddh (new, x); 

end foe; ' 
for const x: t In repSelements <s) do 

reptaddh (new, x); 

ewi§ ? fieV"' : • 
end concat; 

Now we present the opetattare that produce ihojm sequence* from their Input* remh, rtml, 

and frfm. ■ >, i 

remh - proc («w*t s: cvt) returns (u ew. cyt £ jira M t< ft, i i p f lli a fsM ))) signals (empty); 
n: int :•> rep$size(s); 
if n<l 

then signal empty, . 

else , ,* t , < < 

new :• repfereate (U; 

index: Hit :• 1; ^ 

while Index < n do 

reptaddh (new, sttndex]); 
.end while;' " 
endlfr J 

end remh; .'..s.^,;. ■-. ■ ~ 

rem! - proc (const s: cvt) retnrns (new: crt(;max<arep$stoe<sM)]) signals (empty) 
i>; int ;« reptsiseU); . -* r ■ ' ' " ; '' 

then signal empty; 
else 

new :* reptereate (1); * 

index: Int :• 2; 
while index <« n do 

reptaddh (new, sCindex}); « 

end while, 
end if; 
end remh. 

(Max is used to prevent a M* from messing thing* up when an empty sequence Is passed to 
reml.) Trim is given bounds between which ttamantj In the argument semunce are to be 
retained. Trim returns whatever portion of the argument ovtrlapi with the range between the 
bounds. 
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trim - proc (s. eft, low, high: hit) returns (new: c^;max<a,h»gh-tow+l>]); 
start: int :« max 0, tow); 
n: int :- repSsize (s); 
end: int :- min (n, high); 
.. new -treptcrcajted); . :•• ■- ,*<y .. 
for const | int in int$fromjoJby (s|art,end,l) do 
mtmh (new, rf j}) : *' 

end .for; 
end trim; 

The from_to-by iterator generate* the integer! from its f Irst argument through to iu second 

argument incrementing by the third argument; K U like an Algol for loop. 

Here are the selection operation*, first, last, fttch, and tUmmts. 

first « selector () of i from k crijigaojs (e m pt^ • • -' * v 

if repfsize (s) - 

then slgnai empty; 

else select sCU; 

end if; 
end first; 

last - selector of Urom »: crt sig nals (empty), 
n: int :- repSsize (s); 
if n-0 : 

then signal empty; 

else select stn]; 

end if; 
end last; 

fetch - proc (i: int) of t from »: cirt signals (range); , 
if (i < 1) I (i > rep$size(s)) 

then signal range; 

else select stiJ; 

end if ; 
end fetch; * 

The vertical bar U» sugar for the * operation, w this case Iwettor*. 

elcmenu- Iter (coast $:«ifUykWs(cosn»t); 
f or const e. t in reptelements(s) do 
• •' y«M<e>- ■ 
end for; 
end elements; 

Notice the use of the array iterator elmtnts to Implement our own Iterator. It would be nice to 
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be able to assign sequences, so we define a apfvpmtoon. 

new :- $-, 

end copy; * - 

The co/7 operation will often be this simple, bat there are a few types where more must be 
done. We also provide another very usef ut opera***, «q te that #■«•* needs an 

extra restriction on t. .'?*> Vv 

equal - proc (const r, i: crt) returns («f booi) 

where t baa equal, proetypetcont 1 1) reif a>(h e oD end; 

ed><f-i^ - •< * ^.r 

return^ . . ;•,: -• .;■ -^* ■•'. ■..<- • .^>:m s . . 

end equal; 

Notice that we use the underlying* array <f«e4 cparatasn, which awl the <e«a/ op«rat^ of « to 

compare the arrays element by element Now we write theitaefA < 

length - proc (coast j: cvt) returns (h int); 
I :- rep$size(s); 
end length; 

It will be helpful to see some exarapss uses c 

First we define a few types: 

silOO - seqtint; 1083; , , 

si_ - seqCint; *]; 
silen - seqtint; ?ten]; 

Now some declarations: 
a: silOO, 

t* silOO :- tilOOSnull <)• ' 

c: st_:» b; "... 

d: siten :* c, 
if d?len -Othen ... 

First, a is uninitialized, and has room for sequences up to 100 integers long. The next variable, 
b, is the same size, but has-been awigned the mitt seaueiwe. Sh*crih> size of c was determined 
dynamically, it can hold only the nuH s stwaw i aj (Thw fraat v er y u se ful - ft illustrates why size 
should normally be specified Hi declarations.) The same to" true of ^however its size can be 
queried by using men as shown in the if statement Here are a few^more examples: 
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a :«al|d; 

b :- si_$addh (a, 5) 

if si_$last <b> - 5 then ... 

var j: int :* 0; 

for const i: int in si Jelementslb) do 

end for; 

Notice that the first Hne caHs the silOOtcmcat operation. 

We have defined a complete type generator for sequences. This example is atypical in 
that it has no mutating operations. We chose this over a mutable type becau« it demonstrates 
more of the parameter mechanism, since it returns more things, and tends to allocate the 
minimum storage possible. (Allocating the minimum for mutable types is not always desirable, 
since they may need to grow later. Furthermore, even if the objects are immutable, larger ones 
may be assigned to a variable later. Of course the style of use is up to the programmer.) 

4.5. Implementation 

Here we discuss how to implement ASBAL's parameter mechanism. We first explore 
techniques for the regular parameters; these methods are borrowed directly from CLU. We 
then consider the additions necessary for size parameters. 

4.5.1. Regular Parameters 

The most straightforward idea is to pass parameters as extra arguments in calls. This 
works fairly well, except when procedures and iterator* are passed around as objects. When an 
instance of a parameterized procedure or iterator is passed around, its parameters must be 
stored in the object, since they are not available when it is catted. Likewise, an operation of a 
parameterized type must carry the parameters of the type around. 

This difficulty suggests what we call the macro implementation of parameters. This 
implementation actuajly substitutes the actual parameters in and comes up with separate 
pr«edur« fnerators, seJectors* dusters) for each distinct set of parameters. This would seem to 
be inefficient in terms of memory use, but can be good in some situations. Its main advantages 
are simplicity, and the ability to do better optimization of code once the substitutions have been 
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made. Of course, the ejajMre modute dent not have to e« dtnAhMScd. One ton have a small 
parameter dependent suctton wbfcti contains the m f i m i ii lp i ^ n w it to pa ram e ters , and « 
pointer to a large param e ni independent section. T h w J je a H aw i i i il Mt Me that of wring 
linkage sections to bold per process data to a* opeKta^iyaei* e*h fi|g| sextons of sharab* 
pure code. 

There is stHi one proMem however, ft a y miftU to wr«» pttyarm which generate an 
unbounded number of dlWeeent eyyn^ sowp h p iouulyu <to CLU* 

that has that property 

JfnM* • ■ ■•■■■■ J 

. then nan tnastyJWtJ); 



end nasty; >...:-- 

na«ty_b - proc [t: type] <n: hit); 
end nasty; 

It should be easy to see that this generates t. mtmyM, „ r mm0# { &t*» new types can be 
generated at run-time, some kind of run-time data stractore ma* be andntaioed for types. 
Maintaining the data stractons is not too hard; bit h* It it kept m a f**ed-#hx table then k can 
potentially overflow. However, the sort ef recuntoM shonn ■■ail goto EH fcf pill to be very 
useful; Therefore we avoid the pfobbni by ruung it o* to MBAL. <*ee*rtkms In Hie 
• p»«^neasr*are rwartwrn, *m»dirr«Mnt mm p^kmi mMiM^lk dt^rerent abstractions.) 
. There, »^ ss mitaf »s» h a, whh m*m*m>Wm*, tosonrvt tteUcttons en be 
written. W« mu* d.«* wwtvibom m At**t. A mtopoar »»«« ineit for lecwrsrve reatricttom, 
and present the infinite ritwrslWK le» rteoJlh tost s^stflsafll "'^ 
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45.2. Implementing Size Parameters 

Now we turn to the question of implementing ASBAL's size parameters. First of all, 
they are not true parameters to the type, and appear only as dummies, or in positions to allow 
allocation of memory for variables. The basic technique for handling size parameters is to 
store the size information in the variables. This method leads to a nice implementation of xfy. 
just fetching a component at a f Ixed off set from the beginning of *, very similar to records. 
Because the sizes are stored with the variables there are no problems of allocating space for 
size parameters dynamically - the space has already been reserved In each variable. (The next 
section will discuss storage formats for variable size objects in more detalU In the case of 
abstract data types defined by users, the underlying sizes of arrays and strings must be kept for 
the use of procedures receiving the components as arguments, etc However, the abstract size 
parameters must also be kept, f or querying and fo| ML *tte checks required in passing 
pre-existing variables as return variables (see the next section and Section 4-3.3.2). 

4.6. Analysis of Costs of Size Parameters 

There are two major costs associated with size parameters: storage overhead and 
processor time, and both are somewhat dependent on the actual storage representation used. 
Therefore, let us consider the storage efficiency of possible representations, and the extra 
processor time required by size parameters. Part (W of Figure 1 shows the most general 
storage format, one using pointers. This format is simple to use since items are always at 
compile-time known offsets within substructures, although considerable indexing and 
indirection may be required to access a deeply nested item. More efficient forms such as the 
linear format of part <c> of the figure are possible in many cases. Such a Itneaf format saves 
memory and cuts access time because the pointers do not have to be stored or followed. 
However, the linear representation Is not sufficient for alt cases. It Is better to adopt a general 
representation using pointers - we believe that a single storage format should be used 
throughout the system. Having multiple formats hi the system would be bad for the following 
reasons: 
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a) Let this be part of th»j%o duittr: » * , =, 

foo - cluster t^iwl, $Im21 U ... ; 
rep • reeordCt: tfri*f{;100-iiiel], 

end foo; 

b) Let x be declared ai £ootJ O , 203, a n d y m ftwC;2Mffl; a foiwwr wpjammUun pi ulTuhi. 




c) An optimized reprej e nta ttan for x and y it linear: 
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<1> code generation would be made more complfcWed; 

<2> if multiple copies of modules were made, each handling one storape format, modularity 
would be threatened; 

<3> if , on the other band, modules couW h*«dte any itorafe format, the code would be 

larger, or interpretive exeaition would slow processing; 
(4) the entire run-time-system would be move eomptex, while the payoff might be small. 

Thus, the optimization to a format more compact than the pointer format may not be worth the 
complications it introduce*. 

Given that we wJHuse the pointer storage format, kit ui examine the cost of size 
parameters in detail. First, let us see how much storage overhead is introduced by having size 
parameters. The storage overhead for siie rtframeters consists of one integer per abstract size 
parameter per object of en abstract data type, phis one pointer for each array or string 
component, k is hard to assess just how rnueb impact this overhead wW have, because it 
entirely depends on how often variable sit* objects are used, -and whether the arrays and 
strings in them tend to be large or small. Dope vector* have been accepted in many languages. 
and size parameters are only a generalization of dope vectors. We believe that the storage 
overhead for size parameters is acceptable. Besides, this overhead is unavoidable because size 
parameters can be determined, at run-time. Therefore, we suggiot that storage overhead is. less 
of a problem than processor time. 

In examining processing overhead, we consider the bit-copy operation first. For fixed 
size types a bit-copy can bo accomplished with a block move, provided pointers to components 
are represented as relative offsets; and aH components are- packed together linearly. (Both 
provisos are possible, and the offsets can be determined at comptle-time.) With care, the 
components of an object of a variable site type cah be packed together in a similar way, 
a Ithough the offsets wiM gesterauy be computed at run-time, and the order of the parts accessed 
through pointers (i.e., offsets) may not always be the same The time when care must be 
exercised is in the in Rial construction of the object, because the components will never be 
moved later. The only information that should be stored at a fixed offset in the stack frame 
for variables of a variable size type is a pointer to the object itself m the dynamic part of the 
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frame; In that way a unfit; uniform Kortfeformw U«h*«v«d. 

Run-time sire checks; c p wiswi ie me iw ii e ii U i ig uMilwaU , m flfeioir 4J We made a 
decision regarding how chaariy return v«rt»M»r iiw Iptllrfctlffthi rr^ match the sices of 
pre-existing variables; namely, we decided to allow any pr i el a ^ vtrftiblHbbe used so long 
as each of iu array* and stt^t were « le«* a* adfba* lllilt aplatlaJ^bi > thei«ttTTi variable. 
Thus If x were a P re^iit|i^ yai^a» -jrr«awr#^ and Mi)W|lt1^dl i a^etificatton for a 
return variable Jntemie* * be *> me *sv n^ the 

abstract size parameters ((19, W and (80, S0» are dlffwnt, b« batswise the * component of * is 
too small. In gencraMhis Jtto cjw i ptHno l o a u l iM m two W O W of WwrabttfbU type tree for the 
return variable specification and the pit^lstlftg vartaflir^^ most 

be compared, pairwise. 1 For ene^levror r aa*o *Fl^ compon ents 

would be <»mpMired ( aod^ioslsts of th»> tmi>|) i wi«W. ^«-.** >i*'* ■■ '-^^ •■■'* r-*:y- 

Requtring ftlupt*«ae^ to match exactft would FedUM tht processor Urn* spent 
doing site checks because if the ttse* fnae* ea*ettf* tt^^ 
too, »o they peed not be cbesaad, We c^ttd f qr Wmlbimy souis* U^IW sff icluiiiji titytty Just to 

' yWHm a new J<^,m»fo de<a^ wfe^ho^ !<■ obutuui |a|tJ%alliiil!i f%iV th^ noad the 
extra flexibUkyb^oi^w^^a^pitatt, ,u , > - 

,. Jj ^tjbe.oiajnjy^ rtm-flfne sUe 

checks. The storay ovejJieiwt U oot mw audi m uf a Jtit peb^ have coma to accept 

On the r p|bo|. ; bj^ ooj U H a tb I bis y s fitif liti s to mfcteh exactly 

on assignments reduces the overhead signif kandy, but sfrli aM suiuwe. xlnihar tfco flanlbiHty 
of non-exaatUa.paj?wwie* rai4eh i ng i r ~* .*•■ " r < .♦ 

11 mtWf M4NpM* uwHhneitat ilrtUU aej .bed imeuu* though we can ahvaya 
hope some simple, techiiiaj^ wiQ be oeveJepsd freitte ia lu aii i i j ^ 

. practice, ^f^ittf^^ . uoja^ tu p si i at Mlw ai in ar fb J» I* stttubls, but win be 
Undejirable since $uch jyt^ s ajiQ S M w$ taud ta^eayuad orte» itJUftyrTie^tsiirity, increase 
«*«^«fn titr^and genera*** 

■'■• !l: ts.k^. ;,■...■':■ ':.;;.? ..■..''.■: . 



U Noee that omy one peit of strings r» tn aftay of strings hied bt cumpaiott; this generalise* 
to arrays of any jype,. 
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4,7. Summary 

The flexibility gained with site parameters can be expensive. However, size 
parameters are really Just a generalization of the bounds of arrays, and many of the same 
implementation technique* apply. Notice that if sixe parameters arc required to match exactly 
in assignments, we have a scheme very close to those where si« is part of the type, However, 
we have avoided several difficulties associated with having size be part of the type of objects: 

(1) We do not have different operations for objects of different sizes; 
<2> and thus we have prevented an explosion of parameters to operations. 
(S) We know explicitly which parameters roust be compile-time Known, and which may be 
computed at run-time, 

(4) and because types (as opposed to sizes) must be compile-time known, we avoid having 
run-time type objects <!*., objects of type type) at run-time, although we do require 
run-time size information; 

(5) and, again because types are c o mfri te -t in te known, we can perform all the difficult type 
checking at compile-time 

Although it is a matter of opinion, we feel that separating size information results in a cleaner 
notion of type and helps to separate abstract coiicerns fw»» ii iipleitwn tatton details. Overall, we 
are certain of the usefulness of regular param et wt, and believe that size parameters are also 
helpful in programming. 
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5. Areas and Pointers 

In this chapter we present a mechanism for dynamic storage allocation. It allows 
programs to build general graph-like data structures without requiring garbage collection or 
much run-time overhead. Furthermore, the use of dangling references can be prevented at 
comptfe-time. Our presentation begins with «r#aj, the object* that perform storage allocation. 
The discussion of area* 1$ followed by a description of petntgrs, the objects used to name 
objects allocated m areas. We then present details of using areas and poin te rs ; it is here that 
the techniques used to prevent dangling references are dev^oped. 

After presenting the area and pointer mechenisfas, we discuss the impact of the 
mechanisms on aliasing, comment on .the ,9^.0^§^J^^^^^M .^0f & methods that 
might be used to i m ple m en t areas. Lastly we have thpe ea^^|M^ to iHnatrate the use of the 
mechanisms. 

■5.1. Areas 

. An\a*e*i -in : 4t* ' ttat^^ 
somewhat like an array. The idea i> that the area pen** out this block dynamically, on 
request. Areas are based on the collections of Eucttd [Lampson77), but there are several 
important differences. The ma jer difference is titttt ♦ w4lt<Ue<i altdcates objects of a single 
typ^ whereas Ejects ef different types can e<axt« *Pwj»''i#*rea bounds 

only the total ame*mt rf stwag« used n«her tnanlKwn^ of objects of each type 

separately, as collections would. This can lead to better stOrageiftittiation. . 

The simplest allocation method is to allocate objects linearly from one end of the area 
to the other. No reclamation is done, because areas are in the stack, the space for an entire area 
can be reclaimed when the frame it is in is released.* When the size of a requested allocation is 
larger than the remaining space, the allocation o pe r ati on wsH fall. This allocation technique 
brings out the similarity between areas and arrays: arrays can grow dynamically using the add h 



1. We win discuss more sophisticated I mp lem e nt ation schemes few areas later in this chapter. 
However, the general properties of areas wiH hold true for any smpkun entation. 

2. Again, we will outline i mpl e m e nt ation schemes that do more (eg., reclamation) later. 
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or addl operations; areas allocate new components dynamically in like fashion. The similarity 
ends there, however, beowse arrays are rwwiogeneou i aggregates and areas are heterogeneous. 

Pointers are used to access objects allocated tot areas. FoHowmg a pointer is not unlike 
indexing an array, but a pointer's type includes the area In which the object pointed to resides, 
arid the type of the object, for safety. Thus the type generator ptr (for pointer) takes two 
parameters: an area and a type, ptrW) means a pointer to an object of type r in the area a. 
(The type generator ptr and the use of areas as parameters will be discussed In more detail 
below.) The allocation of objects in areas is performed by the operation ptdajlSaUoc. It takes 
one argument, an object that is copied to produce the newly allocated object. The new object Is 
created using rtcofc* The type of pttia^naUoc U 

proctype (coiut t> retww (ptrfa^J) 
where a is an area and fls^type. Alloc %i%no.hfaMurei*orm out ofmmery") when there is not 
enough memory left hi the area to allocate ao object of the requeued type. If cb an area, then 

var p. ptria.iHtl n. ptKa,hit)$altoc<5); -■■■/'■ 
is a legal declaration with initiation. Its effect *• to allocate an Integer in the area a, and set 
the pointer variable p to point to that newly allocated integer. In this ease the new integer is 5. 

Corresponding to alloc, there is a selector, d tref, used to acceu objects allocated In 
areas; the type of ptrW3$d#r#fU 

seltypeOof t from ptrfa^J signals (bad .pointer) 
where a is an area, and Ms a type Dertft^mh bvLpointer when given a null pointer to 
follow. (The null pointer will be discussed below.) An umugared use of derefis 

ptKa,int]$deref(p) 
The standard selection sugar allows this to be written as 

p.deref f 

However, there is a special sugar for d<r«/ which is more convenient than either of the 

previous forms: 

■■- pf ■-■•■■■ ■ " , 

There is no free operation to release previously allocated storage Free would be unsafe, or if 
safe, prohibitively expensive. Having free and requiring safety would amount to requiring 
objects to be reference counted, and still one could not truly free cyclic structures without first 
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breaking the cycks. We fuel that reference counting is teo ««jMMMivf to Justify requiring it for 
all areas. However, particular araa» can do reference tounimg wftfa soma . ■ H iitsnce from the 
compiler; there would atiU be m> expJktt /r*# op«ttt*a«, b^ aetting a pointer tt> iiikHr might 
cause the object previously referred to by the poUittr tebe freed. 

5.2. Pointers 

For each area a and each type t there it a pointer type pttWl The objects of that 
pointer type are pointers to objects of type t in area a. There are five operations of the type 
ptKa.r); in addition to ettoc and <to^, which weie previous!* introduced), we have: 

(3) equal: proctypHconst ptKaA pnWD returns (beott * returns true if arid ceily if the 
two pointers point to the same object ^bt,rhe eamriectftiori tn t he j am e area); 

(4) copy: pcoetypeCcunst ptr(<M]> returns ^ptrl«^> * cipiei Ha argument tthe pointer, not 
the object poUttad to); ptKa^»«fu««^, p«<e^)J»^t^ wiH reium rrttr, 

(5) null: proctype « returns <ptria^3) > aj iw ryi returnt the null pointer, a pointer which 
points to no abject ( Re m emb er that fouawihg ^< null *pe**^ faMi and signals an 
exception.) 

There is a sugar for ptKa,r]$null(); it is nilptr. Notice dutt uiiptr carries no designation of 
pointer type - the correct type can be obtained from content except In the case of nilptrt, 
which will always signal batUpolnttr anyway . ^ The outsources of pointers are alloc and nilptr. 

5.3. Using Pointers and Areas 

Up to this point we have described some features of areas and pointers, but have 
omitted several crucial points. A goal in the design of the area mechanism is safety. In 
particular, we desire to prevent dangling references with only complle-tiroe checks. Prevention 
of dangling references depends equally on several different parts of the design: it is the 
synthesis of these parts that achieves our goal of safety, and not the individual parts. 

The technique used to prevent dangling references Is basically the following. We use 
the syntactic scope of each area object to define a dynamic, semantic scope of the area object at 
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run-time, i.e., we arrange things such that the area i* only hafiteabfe where it will exist when 
the program is run. We also arrange for any object that might contain (or try to construct) 
references to objects in an area, to have the area's name as part of its type. This "trick" allows 
standard type checking to prevent dangling references at compite-Ume Thus, we use the 
standard type checking restrictions of the language to get as much of the checking as we can. ' 

5.S.I. Area Creation ' ' ''" * ■■^-■<'- ■'■ ■ 

Area is a type, and areas are objects of the type awa. The only operation of the type 
area is areaSnttv,, which is used to create new areas, i TMi operation takes two arguments: a 
string (describing what sort of area management scheme is to be used, 1 wjg., Simple" or 
"ref_counted"), and an integer (descrtbing the size of the area to be created, eg., in words, or 
bytes, or some other standard unit such as the sire of an t*t>. Thus the type of areatnaw Is 

proctype(const string, int) return* (area) aignals (bad jrgument*<string» 
The exact meaning of both of the arguments is system dependent: the number and kinds of 
area management schemes, and their names are determined by the language implementation; 
the unit storage size is determined %by the i mpl ement at ion, and the mearrtng of the size 
argument may depend on the area management scheme chosen, as w#H. Of course streaSnew 
may signal if its arguments are improper (eg., the size is negative). 

Although area is a type, we do not allow variables of type area; in fact, only two things 
can be done with areas: jhey may be created, and they may be used as actual parameters. Area 
variables are a bad idea because area assignment is dangerous * area assignment could, result in 
dangling references to the area written over by the assignment 

Since there are no area variables, a special statement is used to create new areas, the 
new statement. For example, 

new a: area - areatnew ("simple", 500); 
creates a new area a, of the "simple" variety and of size 500 units. The new statement is 
intended to parallel constant definitions, and the scope of the area introduced in a new 
statement is the same as the scope an identifier in a constant definition would have in the same 



1. See Section 5.6, which is about implementing areas, for several area management schemes. 
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.position: However, Hie flajbe-hand skfe of ~>fh» -bl' -ftr * nee* Sanson** flWC b« a call of 
arra*new F ur thern weytba new namosiit fr ^mm^vmmvltmmmgfi 



5.3.2. Pointers and Arms hi Reps 

ft is deitrabte to «1tew pointers In the reproentatlero of abstract data types. Having 

< 'pomter* m reps permits dynimk data structures to be bntfe and referred to, one of the goats of 

the area mechanism. However, any type using piHmbu in its repvesMrtotte* taretytng on die 

area which contains the objects pointed to. Let w make eapfcett the notion of a type relying on 

an area; a type it tatt to if spea rf wi an awa if msr St at m%ft aoilibl) be banned via objects 

: of th< type. Thps the types awayEperfajfM and ae*l»Ut»m bo» ftp ini ear area «, and the 

- jSOCond tp« dej^ 

We mentioned our meshed of pi ■ l onuhg dangmt Wfeiences above; we make types 

. depending on w ar« wwtlttbte eobadetto stepe* tJh»tr«* W*w^ unwritable 

by requiring any .type, dap s w d bisj en an area m late th a t an t e as a pajbmuu. "Fnus, areas are 

not global and dependence en them a^ bt eaymtsab ssm»i. i >-tFer easjUptt, a type Ost that 

, attocat^ «s eiemeoti br ■ « » a m ob t eas mm ■ aaioanbs* ftsiaWshni, snwju iioaiau, the onty 

-ant*, an area may be need «> m « paaanwuav We ^ flaw 'deb ian'% atawsJ m t h«t area 

they depend . «■"*, ,•- » '■>{■- «>■>>-•» :; ^,-*s. -,,-,-■' 

., An e^att^tjppodwfmiMBn iwing ae^s^i4i>l 



node - record th<t, rb j Jn . mplt -.--.a,;*. 

.^httaryJreV"'^'^'' 9 ^ " -■*"■"'*'* 



Notice that the type n*rf« is recursive CLU *» oot a^ «^d^ 

but we find them usef* and k^^^^J^^ mm 40^l^ m ^^m f m t ir 



% -■*:■.*■::->-■ «-. -- i- ; .r * ■ '5' Jt.v«i ■■:■ ^K*..*--'- '"«'** *;»... 
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if their (possibly infinite) specifications are the same. 1 A procedure that used a binary tree as a 
temporary data structure might look like this: 
foot- proc ... 

begin 

const a: area - areaSnewCsimpfe'', n); 
bintree - binaryjree ta, IntJ; 
... bintreeS... ... 

end; 
end foo; 

The other thing to notice about Hwrpjrtt is that it takes e as a parameter; )t must do so to use 
a in its representation. 

Why are no other uses of areas other than as parameter* allowed? As was argued 
. before, area variables are dangerous because assignment of areas is an uncontrollable source of 
dangling references. Other uses of areas, such as storing diem hi data structures, or passing 
them as arguments, tend to destroy the static scoping required so that the compile-time checks 
to prevent dangling references will work. Besides, since such dynamic positions may not be 
used as parameters, and ptr takes the area pointed into at a parameter, these dynamic uses of 
areas would not be helpful: the usefulness of areas depends on pointer types, and if in some 
context the type of pointers into an area cannot he expressed, nothing can be done w|th the 
area. In sum, there is no way for dangling references to arise from data structures because the 
type of the data structure depending on an area cannot be expressed anywhere the area does 
not exist. 

5.33. Closing the Loopholes 

As demonstrated above, dangling references cannot arise from data structures. 
However, there are mpre possible sources of dangUng references. For example, the procedure 
ptrtatftalloc is clearly bound to the area e, and we would not like that procedure to be usable 



1. This rule is the same aj that used in Algol 6ft. See (Wijrtgaarden77] for an algorithm for 
checking type (mode) equivalence. 



106 



where a dots not exist. Out might rtitnk, The m • U imrxed to writing out ptrtoj]$is//oc, so 
there is no danger." However, there to : a pottnttol <s^|W, C—totoi llil fumwiliig procedure 
■ definition:. ^ ,-.,. 4< - 

f oo - prodt: «retKcoB»t t: int) retttriM (int); 

end f oo; 

The assignment statement below is pi*ewmabty tegafc 

p ;- fooCal; 
where a is an area, and the type of /Ms 

proctypefconst tot) return* <tot) 

v«r p: proctype(cea*t tot) returns (tot); 

v ,.y \ , cwmr trtt*> tioiSi i t» r»lmp»i' > , tOOh 

... w ... . v .-. ..^.p^ootafc .-:■.....-: ■..■-.-..■•■s •■ .'•■■■..'■■■..■■',■.■■ ' 
J '" ' ' end; v ■•,-.'.. .' 

The code pictured above may follow a dangling reference to the area a, that reference is 
hidden in the procedure object assigned to ^ Wt i»| that ai^ ra«tsm th*t migilt access an 
area '.'Xipinds on that area; If a routine creates an area it dees not depend on that area. Just as 
with other objects, we would like the type of routine objscts m reflect any dependence on areas. 
Most routine*' types do refer to the areas they use. For example, the type of ptr£«/»otf#c is 

proctypetcontt r> ret*m*(ptK^}) 
and that of ptrC<M}iW#r«/"li 

seltypeO of f from ptiW3 *%mthib*Lp#nttr) 
and both types refer to a. To prevent dangUng itfertnce* of Ihoeact exhibited by >h*«bove, 
we prohibit routines from taking an area as a p aramet e r without having that area as part of 
their type. Thus the p i i i ce dun fit tbov* is Wegai Stoct a roittoe must take an area as a 

-ofiejwnetor tt^sibtet* aeiitf ; ^^ access 

-fJW;j$"§M names that- aeea^' s * 5 '. ' 

We are not ruling out anything useful by prohmidfig re^mes Rke/iM. ^ the <yp« <* * 
routine does no* ref « to ai^ areas, then iio abto^ d epe ndi ng on the areas caw 'be. pasted 
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through the routine's interface. And if no objects depending on an area are parsed through a 
routine's interface, then there is no point in the routine's taking the area as a parameter in the 
first place: if the area is to be used only kxaHy, the rout may as well create an area for its 
own private use. ■■ . ■ — -'*r-- "•-■'.■■; ■-?■"'■ ■ 

Another loophole is the use of area as an actual parameter in a position requiring a 
type. For example, if an abstraction has a type parameter t, it may declare variables of type f, 
arrays of type arravtf], etc. Previous restrictions we have made prohibit the use of areas as 
variables and their storage in data structures. Therefofe, we must maae an additional 
restriction that area may not be used as an acturi ty pe par a mcte n 



5.3.4. Summary 



.-.«ij 



H*re are the restrictions we made to prevent dangnng references: 

(1) areas, once created, may only be used as actual parameters; 

C2) if a routine takes an area as a parameter, then that area must appear in the type of the 

routine. 
(3) area may not be used as an actual tyj* parameter. , , 

In addition, pointers may not be used as^panunetef*,..tfea^^ 

array[ptr[«,r]] is a legal |ype, but barlpl whet^ ii of type ptrfa^l is not (It Is not clear what 

meaning can be attached to pointers as parentis anywayj 

With the restrictions stated above /.J^pF^j^,I^J^f!^>1^. I ^ |pBowinjg a dangling 
reference in ASBAL. However, it is possible to create a dangling reference that can never be 
followed. Consider this fragment of code: t *, 
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new a: area ■ ar aa f ne wT thnpte", MQ>; 



"^i!t~ 



begin "'"° 
»rii ,■' .-•--,.. #Hrw«^era«*.«jaita*IH^ 

ptype - ptrfb, lot J: 
tjtype « pwia, prfpel; 
vac p: ptype v pftk MntJtaltodS); 



*be 4ttgtP bk^ te ex^ttd, ttit poia^i OB^Krue^ ia ai^ a by rt^ inrttaltzation of f will 
remain. That pointer wmewdanghog because tttaxflifts Mo inWfc 

However that pointer can never he accessed because At Jgaw (asm!? £«aU, **i£A, hKB> cannot 
be written outside the begin Mack (the scope of H. Evan if the begin block amre hi a loop. 
there is no way to <^aa^ ^ a. dang** 4^^ 1 ^.4tW.«.aj^ .«hoa U would he 



invalid. 



5.4. Pointers and Aliasing 



With the addition of pointers, we arrive tt a universe af objects very simitar to CLU's. 
We gain many advantages: fhafmg, we ahnlry Uhofld general dota structures, etc.; bat we fain 
the same disadvantages present in CLU. For one thing, sharing to a douWe-edged sword. We 
must atxeptffcat a dereferenced pointer may overlap with almoit a n ythin g of the same type ft 
rhaf -oveVfrpwith ari argument, with a' selection, or with any other derefe ie nt c d pointer of the 
same type. What kind of abasing riife should W have in this situation? Oor approach is 
"Gisecf onEtfehd fLsHnpwntJI Atlasmg" rules ire used to prevent unexpected sharing, not all 
snaring. T «^he sharing possible when pofckefs are dereferenced is considered to be expected, so 
no checks are made necessary at a dereferencing. However* ear argument* ats* cannot overlap, 
so rf two dereferenced pointers are passed as arguments there may be a run-thoe check; but no 
checks are necessary if the pohMert themsetves are passed. Note that only (dereferenced) 
pointers of the same type need be checked; no others can poadhry overlap. The sharing 
possible through pointers is not quite as bad a» the sharing potendaSy possible in selections: an 
object in an area is never destroyed by having another object wristen over it; objects in areas 



^Xft $#*■>' 
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may only be mutated. (This U became ft is a selection and cannot be assigned to.) 

Another problem, which was menti o ne d when s el ectio ns and aliasing; were first 
discussed in Chapter 2, U that having an ob^Ktai a cowt doe* not guarantee that the object's 
state will not change. This is because the object may be accessible via another path as a var, 
for example, by following a chain of pointers. However, even though a const may be mutated 
under some condition*, there is a simple condition under whkh It tan be guaranteed not to be 
mutated: the object is not allocated in an area. Tests for aliasing always catch overtopping 
objects residing in *he same, variable, sc* If an object that is physically part of a variable is 
accessible as a const, then we can be sure it wtH not be mutated. The aliasing detection checks 
performed before procedure calls guarantee this. On the other hand, if the object In question 
is in an area, it might be mutated via pointers other than the one used to access it, but Its 
identity can never change .because- the implktt variable it mides in can never be assigned to- 
This is an advantage of dereferencing to objects instead of to variables. 

Note that if an object has con^joneott that aw stored m an area, then 
can always be replaced by repladng the pomters to them; we lose no useful ability through 
dereferencing pointers to objects, instead of to variaWeK The major disadvantage of sharing 

in ASBAL is the same as ite major disadvantage in CLU: sharing makes verification and 

, ■ •. ^ ■ . . •.•.■■• 

proofs about programs difficult, by requiring more complex axioms and proof rules, The 
com pyi ca # on of proofs resulting from sharing is *i> as yet unsolved problem common to all 
languages having pointers or sharing. 

5.5. the Copy Problem 

When presented with an object to copy that contains pointers, should we copy just the 
pointers, or the objects pointed to as wett? TneproWem is that some types require copying the 
objects pointed to, and other types forbid it As discussed in the second chapter, the only 
solution to the problem is to have each type provide a *#Jy operation, which does the 
appropriate thing for that type. 

In CtU, a copy operation will usually copy the objects referred to instead of the 
references, but both sorts of copying are provided in many cases. For example, CLU has two 
copy operations for arrays, called copy and copjl; copy does a full, recursive copy while copy! 



no 



copies only object refwwiws. However, references are always H ii piiU m CLU, whereas they are 

' always expUctt in ASBAJL. leaauar wehaw uipmr WflKW*^ am* Bjyjiiii' at objects can 
physical!* contain o s mps a an ts, espy l aaua l l i ini In >lftW^ iW#Uim^ copy only 'what is 
ph*»ica4iy contained in an object for uenadu, th y mfli ifc j t j tt a l eT seeord* a -ays is of 
this sort Thu gtves na tin? fotewtof i^ n a^wnlantWn^t of lup y W> | for retord* and arrays: 
each coupon*** is ro pja a e^rna; i l ii H i ii ii a o iaa ani oE a**ypm? i¥nieilr>H»ooan1n|: of this sort 

: U umaliv desired, be* ll is a ^t oo n aii n of a typoltm conan** rY liisiii m wrttimj the ce*? 
operation oC tnat type. , : ." 

Thn oapyr pr e b b m it tta e lj reused so anatntr pr uMeni whteh we cafl the «w*w»f *ncr 
fir^ble^ ■ In ^tner«l tlnjre.j»»»ierarc»iy oT i)i|»l rehjiw 1 iamiaiii »»th» object* of a type, and it 
ij not at aU obrtoui whkfr one^ aae www m*4pm&mmim *Mfr:m»W -&p6* equat 

.$*ajity*Jent>J",feir a sea^ 

c*jeas are«a*tv*)e«t if aa^ For other types, 

equivalence of the- steam of ^a^»W,WMim^* m^^^- %kml$mm «&*** ** »•» * 
p^ajraou and i* the uniat daf*n»tho»o* njaof m MAte hi mtoito k t nutucm i equivalence 

,im*m*wmf* **»"? nna» 1 i rii iii mni W e frfiiii t ^ as 

fflPl^ng rnttft bft ■ For imaiyJe, c a wa l Hu ^eii >^>) | a |i (i i il by a ltoka# H»t Two sets are 
considered equal if and^wiy at taey hwwtbe aMm mtin b tri -border of tnc members in the 
linked list does not matter. Tnerefot* e*n^«T RntM 1*1 ^ equivalence 

. relation forset* it hr too soon*? HoweW, n*n* ft gene**? defined iwarsfvety on data 
structures, so each type should provide it 

5.6. Implementing Areas and Pointers 

Our original notion of an srea was a block of storage sJkkated rfcr a stack frame, and 
thaf of a pointer wa* a naufeiae adores* tor pUn n Hy a^ offset Wbar tw> tJae^rmw/ of the area). 
However, many other i n nilh i waatiwu of area* are peettbfe. j^jat took! be block* rf memory 
taken from a storage peo) separate *f mm me stte* -flmV imptoi nn UHib n requires more 
run-time support code, but has more flexibility For exs*np1tv-iKee* coUltf grab more blocks of 
storage automatically if their orlgmat amount was used tffk M*ed sttt blocks would be 
allocated, and the* bteek* used by an area woeM be i-ettmed »e poet of free Works wnen the 



vr'^>i%»"jS# --•s^st&RjSj^*!*-'-. *H."*V* 
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area was destroyed. Thus, very ef f Idem stortfc management would be possible One could 
even go so far as to copy currently cessible areas out to on-line mass storage device* to get 
an effective increase in address space. An somewhat different approach U to implement a 
single heap in which all areas allocate their objects. The objects of each area could be chained 
together to be freed when the area is destroyed. 

Somewhat orthogonal to the source of the storage w tti management. The simplest 
scheme has been mentioned before: linear allocation with no reclamation. However, areas could 
reference count their object*; alloc and the pointer copy operation could tawi code to maintain 
the counts. (The compiler would have to /hafe 10 ru»di^ plater* that are .destroyed,, however.) 
With more sophisticated run-time support, varioaa^ garbage collection schemes could be 
implemented. 1 Our goal haj been to avoid the n««jtfy of garbage collection, but that does not 
mean that we cannot provide it when asked. t 

One merit of treai is that they altow rnany differeiU storage rnamg to 

coexist, if care is taken. Hence, storage management facilities can be tailored to the 
programmer's needs in each problem, even within, different parts of, the same program. 

We believe areas are a Th^Mbfe arid pcjeot t akernaUve to gtoba) garbage 

collection. Pointers can be as efficient as machine addresses, and allocation within areas need 
not be slow - area routines will most likely be hand coded in assembly language. Arguments to 
the routines will be in terms of machine addresses, offsets, and numbers rather than types, etc, 
because they will be called by object code and not directly by users. The ability to tailor storage 
management to the task is probably the biggest advantage of areas over a global storage 
management scheme. 



1. The main difficulty is supplying the information required for tracing. See Bishop 
[ Bishop77] for applicable partial garbage collection techniques. Perhaps these techniques could 
be combined with Baker's ideas en Incr e menta l garbage collection [Baker77], or with the 
transaction fife methods [DeutschUft, Barth77] to provide areas mat do local, incremental 

garbage collection. 
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5.7. Exempte Owe - Qjireee 

■ ■ ' ' ■ ■'.'.,. ....■,..'..' ■'".^..;. ■ Vis* . •: ■ - -'• ■■■'-;■ l ' : ' s'y *"■' ' . . . •' . . 

- JS. - Tfa^rss*! r^v to -?*f^ Mf»r»»«p | <t i' i i| .'* ' i > (i 'i' * «»« 

presented since then. Hen It the new nureienUUon. 
queue - chtMar [* area* t: type] to ~ < 

lufc pt|pd; . .,.. I. , . 






Wt itw » lt«trt tot » tttffolm— MWi of » ^a> r b mi* K aa* art? If 

the qu m ,. ^ «. «. ,*■»,., «. tfU3 £*T» fcr' *. 

******* M,. « li< Mm . 

b*art»e rt« pb*«rr bmefere m do net fe*ve to 

w^WWM^iU S <h* we 



'■»£!"■': -t* ,i;9J 
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Figure 5. The Queue Cluster 
queue - clusterla: area, fc typ«3 U awrte, inwrt, remove, memberi; 

rep - recordCHrst, last: ptype]; 

ptype - ptr [a, element]; ' 

element - record(next: ptype, member 0; 

create - proc returns (q: cvt); 
q « rep${ first, last: nilptr}; 
end create; 

insert - proc <var q: crt, const x: t); 

vaf p: ptype ,:» pMa, eternentlSimodelemeiNKrieii^ nllptr, rnernber x)); 
if q first -nilptr 

tt p; 

else q.lastt^mt :- p; 

' end iff ... 
qiast:-p; 
end insert; 

remove - proc (rar q: cvt) returns <x: t) signals (empty); 
if qlf irst - nilptr 

then signal empty; 
else 

x :- q.f irstt.member; 
q.f irst :- q.flrstt.next; 
end if; 
end remove; 

members - iter (const q: cvt) yields (const t); 
var p: ptype :- q.f irst; 
while p ~- nilptr do 

yield (ptjnember); 

p :- pt.next; 

end While, 
end members; 

end queue. 
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5.8. Example Two - Sorted **f* 

This example U a re-worM«f ; pf Hie efotmpie I* Qhapav i. A* wo* aawtm, we have 

Unproved bags by pa i ■ihfUHth i | il i mH. '"tliif l ii iy 'tlpriii l ll^ -fty liajte. If fit 

rep - reevratcouftt: hit, 
sto* fat, 
foot: pnode}; 

pnode « pttfa, node); /■■ : ..\<r-' 

node - recerttetomeiK: t, -.■.;?.r.:.;^' • -^ •:■.•■ 

«Otmt: hit, ' 

left: pnode, 
rfcrhfc mode}: 

This representation is ii r snt i»lty the siwit «>lh» piev«nu dm wMh the array replaced by an 
area, and array indexes rephmd by pointers. Ftgtt* ft pro go duster. We feel the 

new implementation ts much more elegant Him ft* a wM eeo aea j . In ft* previous duster, the 
array containing the nodes had to be passed m any room* cUt.* to prevtoos chmer, 
whereas here the "passing" of the ana is tmpUdt 



ftS51S»ij< 
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Figure 6. The Sorted Bag Clutter 

bag - ciusterCa: area, t: type] i* create, insert, Count, Hie, increasing; 
where t has copy: proctyptfconst t) returnsU), 

equal.lt: proctypefc*** t, t) retWbo*!) end; 

rep - recordtcount: int, 
size: int. 

root: pnode}; " ' a ;'' 

pnode - ptrCa, node]; ,; 

node - recordtelement: t, a-? 

count: int, 
left: pnode, 
right: pnode]; 

create - proc returns (b: crt); 

b :- repl{ count: 0, size- 0, root: ntlprW 
end create; 

insert - proc (var b: cvt, const x: t); 
b.count :- b.count + I; 

const new^jtr: pnode, allocated: pool - insertl (b.root, *>; 
b.root :- new_ptr, 

if allocated then b.siie :- bjize + 1; end if; 
end insert; 

insertl - proc <const p: pnode, x: t) returns (q: pnode, alkxated:bool>; 
ifp-nilptr 
then 

q :- ptrCa, node]$altoc(node${element: x, count: I, left, right nilptr)); 
allocated > true, 
elseif pt .element - x. 

then ptxount :- ptxount + 1; 
elseif pt .element < x 

then q, allocated :- insertl (ptteft, x); 
else q, allocated :- insertl (ptright, x); 
end if; 
end insertl; 



* 
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Figure 6. (continued) 
size - proc ( co n st b: cart) tectums U: lot); 
s :- b.size; ■ 
end size; 

count - pro (eo««t to cvt) retwu (c iaO; 
c :■ b.count; 
end count; 

increasing: * iter (const b: art) yield* (const V4P*>i 
for const e t, c- tot in in&eostngl (b<f»n*l do 
yieWMe;c>; 
end for; 
end increasing; 



increasing - iter (const p: pnodo) yields (const t, tot); 
if p - nilptr then return; end if; 
for const e t, c tot to InrrnosingHptJeft) do 

yleldfe,*); 

end for; 
yield (pT.etement, ptxount); 
for const e. t, e tot in hKreasingKpt J%n0 do 

yield (e,c); , 

end for; 
end increasingi; 

end bag; 
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5.9, Example Three • Symbol Table 

Our last example is a new one. TtM^iblMia^'ll'tHfiM'rtaiil-'tWiiinBc]. and is 

presented to allow comparison with Alphird. A symbol taWt performs a mapping from strings 

(representing identifiers) to attribute objects in t^Z&W&mttotM?'*^ M the cluster 

header: 

symtab » clusterta: area, attr: type! taam&H$^:b^ft&, ■':'-' 

tweiLbiuc^ istWeJriDCk, lookup; 
where attr has copy: proctype(con*t attr) retunurfattr) end; 
and a description of the operations: <-.>,•*****'* »> " 

create proctype returns (symtab) 

creates a new, empty, symbottabje , fi 

'ft •', 'ukj »••• . • 

insert: proctype (var >; itr|ff,<ttr) fig suits (defined) 

inserts a new symbol i % signals rf#/liurf If the symbol 

U already defeat tb#bjc*k .„.,. r .. 

is_defined: proetype (com* symtab-; strmg) r et u r brf bo o l) 

returns true if and only if the symbol is def mad at this Mock level 

enter _bk>ck: proctype (var symtab) 

performs whatever housekeeping is necessary for a new block level 

leave_block: proetype (var symtab) signals (underflow) 

flushes symbols of top le tt t and didps back a level; signals wuUrflem if 
an attempt is made ■■fime$ilW*0m&lm&pt*- 

lookup: seftyp^latrl^ efmftr 

selects the attribute objefet symbol «lf It signals not-prtstnt If 

there the symbol Is not in the table ' 

A hash table will be used to look up the iyt If. We win use a linked Hst 

for symbols hashing to the same buckefe the hash labia wjftb*usad to fetch such a list. Each 
entry in one of these lists will be a pointer to the data structure for one symbol. This data 
structure consists of the name of t|te symbol (a ettlnfl, and *b*,«t«* «f entries made for that 
symbol. Each block is represented by the list of the symbols defined In it, and the blocks are 
stored in a stack. An actual statement of the reurwntation should make this more dear: 
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• ^•' • ^*"^^a^^a^^fcW^Po« .vfffff 

fniji tihlf hethtabl; 
blk^tk-stacki^blQda; 
»ymiist - ht&Kpjvmjnai, 

n - sem* tattgtr; 

bucket - 4itf^jyflM**l> 

tym^entry - recsnftsymbol: atffepg, 
•tack: «ttr_*kJ; 

attr**tk - stickle attr.«*frtJ; 
attr_entry - recoftftevel: Jut, 



fOir^ 



w-"?& 



See Figure 7 for art cxaropte of i iymboHatfete I ii|n ^HfcHwi att*¥ tow»e opertuioiu have been 

oi^NfiiiNti^iNUiiBiflai^-' : *-"'•■■- >■•" 1? s, ^> '•■■** ~* »^ ^«'^ 

<D create: proctwet^xetiiwi^^tackUiJ) 
create* * new, emftyiOKk 

<2> puth: procty^etMratackl^oeiMl t) .*, : 

- <3>. pop: PT** , tTrTff rr ttrufi ■ rl> nlm ■■(0 il— MiaadMfk^V 

•elects the top element of the Hack; 

■■.■-:-/■ '»-. . ■■■• •:•''■-•;. '■■.-.:. -■-' ■•■■■..-. ■■:■'<.-. <•.*•;" ''.-ii'o? t». : :' ■'•' -;■ ■ ■ «'. - : -f.-- •■;•<. r^; -./v,;.' -...■ ",:;.- • >i:r 

<5) «mpty:proctype<cm»t ttacktafl) mwgtheei) 
The qperatfcxuftf /Wtoil that effuse, 



119 



Figure 7. A Snapshot of a Symbol Table 
Below is a drawing of the representation of a sjfmbo^ tab er the following operations have 
been performed on it: 

create . 

insert: a, xl 

insert: b, x2 

insert: d, x3 

enter_block 

enter ..block 

insert: a, x4 

insert: c, x5 

enterjblock 

insert: f , x6 

leave_block 
(Assume that a, c, and / hash to the same bucket, and list m\$ stock are implemented with 
linked lists.) 



level 
blocks 
hosti-table 



^ 



> b 



> — * — ■ 
• a 
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(!) create: ' p rocty |W » i Hm n i t ma' s ,>)) . ' 
rmufiu «iiiw r QlWt X . hk 

returns a new tot comtoUag of to wgumnt yfc» a »tw ■i pifi f nt at the front 

of the Hit; 

the new ekmwm to made with (fcsfy 

(3) member*: ItertypedtotfMJ) yWd^t) 

yields -the elements of the nit in order 

Now we present the operations of the symtob duster, one at a time, 
create » proc r e t u rn* (k crt); 




s ;» reoiifevefc 1, 

Mocks: Mk. 

ha$h^fatnR 
btkjttkSpushfcblocks, 

Thus cr**u returns a symbol table si block level I* the o u t ermo st Meek, with an empty hash 
table, and a sing to block with no symbols. 

The ftwrt operi^b^ to fairly eornptot, bift bi^m down tnii several s to w ple cases. It 
works as follows: ■ *■ 



(1) the input string to bashed and the bucketsmrched to so* if ft to present; 

(2) if the' symbol to preserrt, an^ tt rwt defmed « ^ anrettt btock level, then a new 
attr^ntry it created' and pushed onto the stack of entries for the symbol, 

(3) if the symbol to defined »t the current bkxk to-ret then rfs/Tnnf to stjpiHed; 

(4) if the symbol to not present, a new attr_tntry to created for the attrthutes, a sjmutnttj 
to constructed for Hie symbol, andMt to snwtjd intpibtocael list; ' 

(5) lastly, the symbol to e nt e red on the list of Jsfia s d sj iiwe to f or the curftnt btock. 
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Insert - proe (var t cvt, con»t sym: string, attrib: attr) signal* (defined); 
const bkt_num: int - hasMsym); 
var p: pjtymjcnt :- nilfitr; 
f or p Hi bock«rtniembett<».hMh Jablatbi 
if ptsymbol - $ym 
then " • 

if attr jtk$empty( P t Jdick) cor pt Jt«ck.top.lev«i-v-»,level 
' then * ■ 

attr_*tk$pu*h(pt4Uck, 

*mjnM$£0; H *,»evel, 

^^^^0 a)Bje^S7B«Bia^ MHI wNFw r i 

' break; ' 
else signal defined; 
end if; 
end if; 
end for; 
if p-nilptr 

then . 

p :- ptrta, $ym_entry]$tlloc{ 

symjent!7${symbofc sym, 

stack: attrjtk$creit«0>>; : 
attrj«k$pusWpt4tack,attrjintryttle¥el! sievel, 

attt^ufcjs; attHb)); 
s*a*hjab :• feucj^liafij^j^^ 

' endtf; 
const newblk: symHst - tymKsttcons(p, blk^kltop(sJx*3c>*>.symboU); 
blk _$tk$top<i.blocks).iymbolt ;- bkxklUyinboU: newbtk); 
end insert; 

The operator cor (for conditional or) evaluates its second argument only If the first argument is 
false; its value Is the logical or of its arguments. There is also a cand operator: conditional and. 
and it evaluates its second argument only If the first argument is true. The regular and and or 
operators are sugars for calls, and therefore always evaluate both arguments. The cor used 
above prevents our following a nuM pointer. 

The rest of the operations, H-dtflntd, tnterjblock, leawiMock, and lookup, are 
straightforward. Notice that Uavt_block must throw away all symbol definitions for the block 
being exited. However, it does not throw away an empty *ymjttk\ In this sense a symbol, once 
entered, is never deleted. 



122 



Isjdef toed - pros town* k en, *ym #rim%) Htmnm tou soeD; 

for conrt p: p^ym.cnt in bwekert n ? |f»f» ; i«(t huhO l bW»»h Uyn>)tt do 

' w fnSfMMf » t*nt - 

d :■ (Mutr^Mktefnptfotjt^ 

return; 

end If; 
end for, .,.. 

d >f*i$e; 
end tsjdefined; 

enterJWdck - prde f#mt i: art); 

Wk.tfkSpwtfrfsfcloekj, btockKiymboti; lymlUrtcroBtem); 

s.level :- s.tevet ♦ I; 

end enter Jriock; ■ ; - -:■.-.- m,?*,,^ -»* 

■■■; *k$A.^ 

leavejrfock • pre* (ear 'k c?t» rtfiwifc (nn d«ifkn » ) ; 
• if s.level - 1 then rifnel un de r fl ow ; end if ; 

s.level :- s.levef - t; v ■ > ' 

for var q: pjqNnjM* in symHrtti iwii i | »< ia(bl^ Mt^^>^^i)jymb<^ do 
attrj«k$pop<«qT.stack>; 
end for; •''"""'' "V ; "" t 

end leavejtfoefi; ' '* 

lookup - jetactorliywi: 

fdrMitft'' " 

if pT symbol - »jrm ., 

■ THfCTT " 

then cIcmI not^orcMnfc 
ehtt Mteet pt. 

■.''Wijf*""" 

end for;' ' ,„......■ 

end symttb; 




<;< ■^(f.K'V^fl 



uV^v 
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5. 10. Comparison of Area- and Stack-Based Programming 

There are considerable dtf ferences between designing Clusters for objects in the stack 
and tmes for pbjKUt to be allocated in areas. Unfortunately the user must flan ahead because 
abstractions designed for the one storage mode wUJ rarely be convertible to operate fin the other. 
The reason is that stack- and area-based abstraction! take d^fwmt parameters: stack-based 
abstractions will use stie parameters, and area^nxsfd abstraettorts will take at least one area as a 
parameter, but not usually any size parameters. However, if the situation is examined more 
closely, it appears that stack- and area-based abstraction will always be different abstractions, 
so intetchangeabilKy of them is not realty desirable, tor example, stack-based abstractions will 
always be bounded, whereas area-based types wilt usually be unbounded. Often Just this 
difference is enough to cause the functionalities of operations to be defined differently for 
stacks as opposed to areas. Another difference li that arrays win be used to represent lists in 
stack-based abstractions, but fan* linked lists with pointer* will be used in areas. This matter 
of bounded vs. unbounded abstractions needs further research.. 

5.11. Summary 

We have presented areas and pointers, features that add dynamic storage allocation 
and list processing capabilities to ASBAL without requiring garbage collection or great 
run-time overhead. Our pointers are soft, they may never point to garbage. Pointer safety is 
guaranteed by compile-time checking which prevents following any dangling references. We 
extended our aliasing detection and parameter mechanisms for areas, and discussed a variety of 
possible implementations for areas. Lastly, we presented three programming examples; two 
were new implementations of previous examples, and one was a new cluster. We believe that 
the concepts behind our areas may be useful in other languages besides ASBAL. 
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6. Summary and OoawHnlMW 

■'.-....'.-.■-. ■■'•'? : ■ -- '■■:■■. .;>s*"* -:-i = i a -• :-iA l<- ** ^ A: " i*.'--'' : " : --- 

We have designed a program m i n g language inoafjmrattng abstract data types that 
does not requfre gart^ ooeattten. Ovra^rea^ ^Wtisr^LU at aiaiis and change or 

extend i| st» needed. The major ^ changes were -fi ^illi, ^MyiiM^Hn#; : ' ; s«Mwa%(f<:" "tnodeJ of 
computation. We f esmohoed a W^ ao>1 wrwwoit laittftt I Qgt DretcrVes many of the 
objea^ortcntad concepts of CLU, although not -Ha thetr l«ail form, these changes were 
neccsuuytDofeviaw the neui f e i ga rb s gt tuB a d i OW 5 '*'- £ * ;; - : 

. The rmjor ex tension* were ■*■;?■ : ::: ' : ^■'■■'■ i 

: (U Selectors - a mechanism for sxcetslng c^jsctt ^ 
<2> Size parameters ■-. a feature a||pwief, control o?w %,sii*<K^»r*»»h^ Wt handling 

size automatically whew control fctrt o^^ 

ob lect sizes most he bounded at creation; .,«,.,. 

(3) Area§ and.fpfctterf -, a raechaol|m for dnufnk storage alaxatkm and manipulation of 

list structures wtthtn the framw^oi the stacs. .*,. 

Of the three extensions, two are just generaMzanons of commonly accepted Ideas, from their 
present use to the realm of abstract data types. Selectors generalize record and array component 
access and site parameters generalize array bounds and dope vectors. 

Areas extend the language in quite a different direction. They are an orthogonal 
addition to the basic ASfiAL presented in Chapters 2 to4 llewev e t . areas were added so easily 
because ^the 1 ebjett^rtt& semantics of the earner chapters was designed taking areas into 
account. For example, if* we were' to delete 'areas from AS1AU the copy pr o bl em would hot 
arise. Without the copy problem we might be able to have a system defined copy for all types. 

-.. . ,,,,- -.■„•., ...• -. -■■--■•■••>'■; • : '- 1 " ;W j rw«;j Id i^v^nHia^-'^m. ■ - ■. *:v- ; - 

th the absence of areas the whole semantic model might be < sfcjnif ls^sJto_'dWerent: The area 
mechanism was ta%eh/ inspired by the cotl e c t teos of Eocnd ILamp*on77]. 



-'..--. '-*Jij?.V- '---■ •"■ 
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6.1. Suggetfions for Farther Research 

There are many areas of possible further mvestjgatio* reUted to the design of 
languages supporting abstract data types. Flrft, let. us describe a few concerning ASBAL 
directly. One obvious extension of our work if to implement the language we/ have designed. 
An implementation would give direct evidence of whether, features, we daim are good really are 
worthwhile and efficient enough in practice. We be(ieve that the mechan^tnu for returning 
and size parameters are the most questions. i»o jnechanisms were the hardest to 

design, and are still not completely satisfactory. _.A redesign of these parts by other researchers 
might be worthwhile. 

A rrrare ambUhwi undertaking would be extenstons to ASBAL for systerns 
programming, although any implementation would need tO,exiend the language some. Here 
are some systems pregramming feature! that might be added So A^BAL. 

(1) machine-oriented- types (such as words, bytes, bit strings, addresses, etc); 
(?) type checking loopholes to allow certain unsafe operations to be performed; 1 

(3) controlled excursions into assembly language for other unsafe operations, such as 
control of input/output devices and special hardware (e-g, cache memory), process 
swapping, and other features for DuiWmg higher level parallel programming 
constructs; 

(4) user-written storage management packages, possibly in the form of new 
implementationaof the area type. 

Another suggestion for further hw»est%athw is mcorporatton of our area and pointer 
mechanism in other languages. We beueve our scheme has merit Independent of ASBAL. and 



1. For example, memory allocation, involves the unsafe and t)tpe-incori>ect conversion of a block 
of memory words to an arbitrary^ Much wpr^ adoae on the question of how 

often and how *» mug, be used, if at alt See Euclid 

[Lamp son 77] for one technique of bypassing type checkit^.. Thf^n^hanism fvesented there is 
simple but inadequate, because there is not enough control ever which programs may use it, 
and how they use it. 
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it, would be interesting to see if it did haee .aggdnBftBna &m&m, Ceenpartson of our area 
mechanism with its parent, Euclid's cotecoon fnechaaea* might aiat la* aee^wlaU. The size 
parameter scheme could also be used in other ling naga rtsajghi, since it U a fairly 
v tlr«1|1tntowM vt "-'\ rv1 " **\'; 

Adfrferent ttne «f research is lb design' ft language with the same goals as ASBAL, 
bwt uimg static rather i^n st*^ ateca^ e! snwage'for objset*. This in%ht involve a 



synthesis of tfnY'CLiJ chaster and the opa coacept of type managers. Each type 

rnanager wboU statical!? possess storage and would allocatt and free to own object* within that 
«ort|^ 1 The user's vtrtabtes fh rt* tfect woo&^ object references, which 

wtwW be Hrt^metf dnt^^ moneger would 

distribute only references to its objects; the objects woatd be kept in its private storage, 
because the reference* woo* bt mtcrptele* ^ them, they 



^- f W-ttrtf from r nn vrnM irrtrr rtiir Tyni wi&tf Qt F *'"' " * ; " ? "'' **'*" .""" 

. A static aUociftnm xfbennvmigbt kit* 'Wry weKpeltfculerb; fW systerns programming 



languages, and could be simpler than ASBAL. It wugM abo leek more ftke CLJJ since object 
references are used, wd^ snm^c^ freeing the 

storage used by irnuxesstbte objects. Another diTOcuJb/ weoh} be pMametenamg type 
managers/ SttH, we believe the type manager ajenench 4| euite pcoirdsiag, and might be 
developed into a simpler and rrrare practkal laitgara than ASA AL. 

6.2. Conclusions 



We believe we were successful in deajgntngya Isiajaogi wjabaanenact data , types that 
does not require garbage coMattieo. And we ■ behave the : langaagi is built on a firm 
philosophic*! baiis* which leads to a, i 



1 The allocation of storage to the type managers might not be completely static, but would be 
simple; the type manager* would have WWlm iMfO i i i MHf for he aBocattoB and 

^:^m*gntbe.n«*«l to devnea scheme » ^rhahfetr f or aueues («y) coqld deal 



wiih *r^of*a*y jmj**** #*&, #"'W$M WWW m *<*****" 

nw^gerfore^jeuesbf each^ype. ■ >.-*..■...».— *t »«-«n....» ,» .... • ". .. 






,- . S» P*)j^*^*^V ^A'-V ■.-"-"-.:'■ :*■ ■ ': 
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ASBAL does not have the elegance of CLU. But we did not expect It would. There 
appears to be a trade-off between ele|^nOE c pnd juvd e£ficienjsy, ; on the other. 

CLU's semantics achieve elegance through the use of a simple and powerful semantic model, 
which unfortunately requires fairly complex run-time support We have traded, away some of 
that elegance for a more efficient run-time mechanism However, we fiavi tried not to 
compromise some ok« linpomnt aspect* of CLU Oiirp^yudice ha| been- 'toward a 
completely type-safe language, type-safety being a kej to the abstract data type methodology. 

If ASBAL does not have CLU's elegance, neither does it have the simplicity of 
traditional languages, for example -Pascal. In faci CLU is more complex than Pascal <and 
simitar languages), but more because it has a paramsfer mechanism than because of abstract 
data types. 1 Yet ASBAL is more complex than CLU. We believe the source of ASBAL's 
complexity is the constraint of running within a ttac^ aMne4,usis)g an a utomat kali y managed 
heap. In a sense, we have bulk ASBAL .oh *■» liiapumprtais foundation; but one for ced on u» 
by bur requirements. 

ASBAL represents a synthesis of ideas from several languages, and several semantic 
models. We feel the synthesis was profitable, and hope that our work may suggest and 
encourage more investigation in the area. 



1. Pascal has been criticized on the grounds that it is fee simple in this respect no Pascal 
program can deal with arrays of any size. 
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I. Syntax of AABAL 

Here wo prose** the fuM, content-free eyfltex of A« The metetsnguaga used is an 
extension of the usual B*e*u*-Neur form. It "hat eeWft'syMM symbols, •nrf ibelr meaning is as 
follows: ? " 

I 1 - enclose optional parts of a production} 

I \ - eftctoee an Horn wWch wy be raa ost e d a ny number of times, including arte* 
| - separates choices, thus ' • | b * generate* either « a * or • b *» 

( \ - are used to group items and eliminate ambiguity} 

-> - used to separate the left-hand side of each production (a nonterminal) from the 
right-hand side (the string it generate*}. 

f^>m»f m^d tynibo** aro T sp rat o nl ed by lower case Wenhhor*. At* other symbols ere terminal 
(excepting the special iwatatanuwej symboknV 



^-,"«f'if««! i *'-«fVv^" T!» «4r*JS®$piZi!f l i : <!- -'->—- 
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I.I. Formal Syntax 
I.I.I. Modules 

program 

modulo 

cluster 



''*>*: ,* : ? 



clustermodulo 
procdef 



," -> modula ; | modula j J ''*''"■ 
-> ckrttar | procoaf J Hardaf | wWaf 
-> id - cluster [ fcperms^itids »[ restriction. , ] 

clustftrmoduie { cluilaVa&ieVa }endf w], 
-> procdef | itardef | toWat 
-> IcT -proc J fpsrms ]?"(*[ %•* f f ■ *M» 1 » 

[rattricHemi J body end [ W ] r 

-> id - Iter [ fp*rn» Jf^g. [ fykk ] [ Wgt ] » 

[ restriction* i J body end[kl It 
-> Id - selector [ f perms ]< [ Ids t^type^ , Ids : qtype } 1 ) 

of stype from Id : otype | faTas j if [restriction. , ] body and [ W 1 
I» 2. Parameter* and R«etrtctk»n» > 

<P»™w -> [ f permitem { , f permitem J ] 

"> [ [ fperimtem { , fparmHem } ] [ i ids 1 ] 
-> ids : ( Int | boot | ckar j type | area J 



iterdef 



seldef 



fcparms 
fparmitem 



The above three productions are for formal parameters (to all definitions 
except clusters), formal parameters to clusters, .and the items in formal 
parameter lists. 
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aparms 
■parm 



-> [ [ uparm £ , aperm J 1.1 | exp | , exp J I J 

->exp[qtype 

The productions for aparms and apart* ere for actual parameter*, which may 
be expressions, or type aaejclffcejljejej#f*^j|s^^ 



restrictions 

restriction 

restrict 



-> where restriction { and rwttlction ^ee^l wfcere J 

-> id ha» restrict f .restrict V ^ 

-> ids : ( ptype | itype JaeUype ) 
1.1.3, Arguments, Return*, Yields, and Signals 
fargs *>( t fatten) {, faitem VI ) 

-> returns ( [ ids .* stye* { ,ies : *(»<•*} 1 ) 

^ |iej£s{|jr^^ 

->( var| const )stype{ ,«type} 

-> signals ( f sigite* I , f sigitem } ) 

-> id [< slype {, slype})] 



f aitem 
frets 
fylds 
fyiditem 

fsigitem 



The above productions are for f omat«atsjweawti^a1a ^ r e tWtti « aH , ykrlds lists, 
and signals Ksts. They are used watnly in < 



1.1.4. Statements 

body -> I equate y i f statement j 1 

equate -> id - expi 



statement 



-> deel 
| assign 



.Vf**-»«5K 



| while 
jfbr 
| with 
} except 
| begin 
| return 
|yWd 
| select 
| signal 
| invoke 
| tagcese 
| break 
| new 



decl -> var ids : qtype € , ids : qtype V :- exp I , exp > 

| var ids : type | , ids i type } 
| const ids : qtype C , ids : qtype \ c exp / , exp \ 
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In the first and third productions for dtd, fne number of identifiers on fhe loft 
must equal the number of expressions on the right. 



assign -> ids :• exp € , exp 1 

There must be either one expression, or as many expressions es there ore 
identifiers. 

•f -> if exp then body { ebetf exp then body J F else body 1. end [if J 

while -> while exp do body end f while j 

for -> for forded { , forded } v In invoke do body end [ for 1 

| for [ id* 1 in invoke do body end [ for 1 



132 



forded 


-> f vs* } coast Y kit : qtys* 




W*th 


-> wflfc { var | coost J kl — s«» do bo* 




OMcept 


...■■» sistomsnt «— pi C whsosrwH > 1 otk 






Therm mm* b* st kwst sns ghowoi'si or of 


^^T^^!!^^^^^^^^ 


wtsrnwm 


-*■ worn ids 1 ftPf* 1 1 itstsoisnt 
j wfcai kb ( » ) : ststamsat 





otnorsarm 



begin 

rotMrn 

ykeld 

select 

signal 

i evoke 

tagcase 

tagarm 



In the first product*** «N the 
types Of objects kt tbe »«■» order. m#. 
throwing mm? tn* objects sent etas* eMlMi 
objects need riot betboso nwforst iiiiiipltfirii 

-> others ( cm* id : ojfepei t 
|«the»<*): 



My tbe 
kt uses 

types or nt 



Tno. firs! preduetkw'i object is • string (so fee ffopt mast 
and is tbe name of 



tostctef), 



■^10 -apey soo.-'; 



M'-rtSHiSi 



-> yield [ ( [ e*p£ , exp |J> J 
-> w h et o«p ' ■ •■ .- J .. 

->*kjl^W [([«*»(,•** J J) J 
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There may be only one others arm par tafcase statement. All tags must be 
accounted for in each tag ease statement. Al^t«pa named on the sjime arm 
must be for the same type, and the type of thetpcelty declared identifier must 
match that type. 

break -> break 

new m> new id : area - exp 

The expression must be an invocation of areaanew. 

Several ofthe above i ta la wen i a ere a l low e d way in particular contexts. The 
return statement is legal anty svpr oc oa frr o a end iter atorsj yield is legal only 
in 'Itei atorst aaieet is iogat wdy in soloelom e n d'fc r eak is allowed only in for 
and while loops. . 



1.1.5. Expressions 

e*P -> exp bop exp 

| uop exp 



JXokp) 

| literal r 

{selexp 

j invoke 

| qtype f id | aparnw J 

| up 
(down . 

The last four productions of «%£ need explaining; they are for routines. The 
special routines no and down are allowed only in clusters and convert 
between the abstract and rep types. 



selexp -> id 

| exp . id J ( exp £ , exp J ) 1 

J exp E exp ] 
jexpt 
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These terns are (in order* • v a r ltb w. , u ls ctHw , array todeab* and points 



bop -> ? 

I- 



1*1/1// 

I.H-U 

I < I «- 1 - 1 >- 1 > I -< I «*- 1 f- 1 ~>- 1 -» 

|*|cmd 
IM 



first *» ttnd *est Ugh***"* * flw second h« tightly, etc, eo the lest 
#* MMwll 1i#Hhr. yora ropOlllpJti « 0» > l i - i the mm* few, except •*, 
'x op y op z* mm Ik op y) op «•> Mr**/**** .tens «k as <y ** *r. 

uop ■> • I « 

literal -^<rHfit|ch«itt|«tf1H)booim|nylMt||ffMt 

|qtype§{exp:exp{,exp}] 
I qtype • I exp .. exp : exp ] 
| qtype I { Ids : exp { , idi : «p J } 

The second and third Knot ore lor tha array constructor, which hos two forme. 
The lexpQreapj ♦ oppjj ♦ «, oop^ f 4em weans on array with low bound 
exc^y and n a tawo i da , expj through oap^' in increasing order. The 
t •*Po - «*i : ««02 T term KM* en arref with lower bound exp^ upper 
tKwnd.wei(|exp -;i,eicp 1 V ^ t ;dj ;iltii oi d| .)oaiaiM of exp^ Tho test 
produdton « for record conatrwetora. 

boolHt -> trt* | f al«a 

nulHH -> nil 

ptrlit ->nllptr 
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1. 1.6. Types 

type 



ptype 

itype 

seltype 

fpargs . 
fpargitem 
fprets 
ids 



» inl 
|bool 

| char *<«'- 

j null 

| area 

| string [ j exp ] 

| array [ type » exp „ expd -,■*■- 

| record [ids : type £ , Ms: type } J 

| oneef [ id. s type f , ids : type V ) 

| id [sperms 1 
| ptype 

| seltype . 

| cvt [ ; exp ] 

I ptr [ id , qtype J ; •• -. 

»> prpctype fpargs J fprett ][<•*• ]■'■."» 

-> Itertype fpargs fylds [ (tigs T 

-> seltype [ fpargs J of stype from qtype [ fsigs 1 

-» < [ f pergitem { , f pergitem J 1 ) 

*" . "i 

-> I var | const V qtype lf «..' 

-> return* ( [ stype { , stype } ] ) 

The productions of typ* ere for those positions where a v-typespec is 
required. 
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1.1.7. §t*f Types 



stype 



sparms 
sparm 



jijj 1 ?fS*j 



:»> : 4Wt.. 

|bool 
\dmr 
I null 
{area 

I string [[ t sparm ] 1 

| array [ stype [; spww^ sparw j } 
| reeoN [ W* : stype { , lea ta%pe^ ] 
j «■*•*.[ ids : stype £ , Ma rj stype} ] 

|id[ sparms 1 

Jptype 
|ttype 
| seftype 

I crt [ { j sparm J , sperm I J <L 

| rep | [ jspee*} , ape** |*|j « 

| ptr [ W , qtype J 

| " ■ ' .f v " '• ' •••■ ■- 

->exp j» 
An stype » usee: far vMy*esa«*V 
1.1.8. Question Mark or Star Types > 



■■^'i^;-;''-.| 



)]' 



qtype 



-> lilt 

| boot 
| char 
| null 
| area 
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qparms 
qparm 



| string [ [ j qparm ] ] 
| array [ qtypa 1 i qparm , qpSrm J] 
| record [ ids : qtypa I, ids : qtypa J ] 
| oneof [ kb : qtypa f , ids : qtypa > J 

| id [ qparm* J 

|ptype 

|itypa 

|sattypa 

| cvt [ [ j qparm { i qparm J ] ] 

I ftp [ [ j qparm f {ipor» } ] ] 
| ptr [ id , qtypa ], 

-> [ [ aparm J- , apar* J J [ ; qparm { , qparm J J ] 

->axp|?idf« ; 

Tha nontarminaliff«p» axpands to v*?-typaspacs.*'s and fldV 
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1.2. Syntactic Sugars 

There arc quite alow syntactic form* w hich are *sqgafer< tar normal invocations. These 
forms aro cataloged below; x,, % and x ere expressions, R is est iaoMtMer, eotf T is the syntactic 
type of x (i.e., its type as declared in a program or d s tai ari t ia da y the caiwp i l er). 

Sugar 



x.n 
x.n :<■ z 

*{yj 

x[y) :- z 
x ** y 
x * y 
x /y 

x//y 
x + y 
x -y 

"lly 

x < y 
x <- y 
x -y 
x >- y 
x > y 

X *w<« y 
X "v- y 
X <v>- y 



Expansion 

TfMxJ 
Tfput_n(x, z* 

TpeiBjeaaa&^y'jf 
Testers**, y, r) 
TipowofiJtt yt 
TlMftt»r 
TtdMsvy) 
TtMQd^y) 
Tladdfo, y) 
TfkOB^y) 
TfcencaKx, y> 
T*«%y) 
: : Wt^,^ ■* • , 
TteoaeKx,y) 
TJgofcyJ 

M*«y) 

*fx ■<*#/' 
„*<x -y) ; 





X <v> y 








•Kx>y) 










xeVy 








Ttendfr, y) 










x |y 








Tter<x,yJ 










- X 








leMimisfx) 










~ X 








alssHsIf^ '^'- - 


'H's- - 






1.3. Reserved Words 














and 


char 


else 


free? 


Her 


of record 


settype 


then 


when 


area 


cluster 


etseif 


has 


ttertype 


©nop* 'fdp' ' 


signal 


to 


where 


array 


const 


end 


if 


new 


others return 


signets 


true 


whMe 


begin 


cor 


except 


in 


nil 


pro*' ■' returns 


' string 


t*oe 


with 


boo) 


cvt 


false 


int 


nHptr 


prodypo sotect 


lag 


..UP'. ■ 


yield 


break 


do 


for 


is 


nuR 


ptf selector 


tagcase 


ver 


ytSMB 


cartd 


ttown 
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14. Terminal 


Symbols 


id 


^•Iph^.alpha^dliJty ^ 


alpha 


-> letter I 


letter 




difjt 


->0|u.|» ' 


Intlit 


-> digit { digit} 


charllt 


->'(char_rap^y« 


etrlit 


->"f char_roppy* ^ " 


char_rep 


-> printing |\*pec*el 


printing 


-> any ASCII charactar aueh that 37g < octal value * 1 77 8 


special 


"* * * repreeants • 
1 " X repreaenta " 

I \ % represents \ 

l n * wg|*fe^ a lBX(ne|#lliie, ) 

I I Vrapre.enl.HT (horiwntaUeto) 
Ip % repreaenta FF (form feed) 

. *.. ■■-.' ; ..*• ■:.->•■ <* f iPSPr Wt"mPIs IMF'PWW' 

1 r * repreaenta CR (carriafe return) 
1 v t repreaenta VT (vertical tab) 
| octal octal octal 



octal 



| ~ | 7 
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H. Baals Data Tyya a af A8)BAL 

Here weatattfe operations of the baste type* of ASBAL Ut us first describe the 
special notations used. The sreumentt to ftjii italg fthe ei»hrt> objects, not the Syntactic 
expressions) ere ceiled <erg 1', 'erg2*, etc, or just <tt» ■ ■fguw e J i r If there is only one. If en 
operation signals 'foo', we say that #00 occurs. Use %| sperahon nemos is dropped 

where there is no ambiguity. Ari thm e t i c axprs Mta m p l id ifl s y n frnap contained in thetteirt ere to 
be computed over the domain of ett integers, not iust the domain of Vm type int 

Some definition* involve restrictions. H a defetMen =h*e e restriction, it Is Either e 
standard where clause, or of the form 

where each T { has operjriectj ■ 
which is an abbreviation for 

where Tj has operjaeeJ 1 ,.-,T n has enmi^ed^ ^ 

Several definitions wfH involve tuples, A !■»*<* f4f]^,i£*L*i«^. The Oj arp potted the 
components of the tuple, and a) is eaMed the 4*" ieomponent. A tuple with n components is called 
an n-tuple. ¥re sfeo define the fottoerfm operefteie»^^ - *' 



S«o(<a^v l .e n |).e l p,..,. i , ■.■;-: ^.-v^^r , : ^ 

A - B If f (Size(A) - SiieW) a fMU s I s nJlej - hjj 

<a, .... b> J| <c, .„, d> ■ <a, _, b, c, _, d> 

fTont(<a, „., b, c>)»<a, .-, b> * !m *; ? ■^"-^ ■ 

TaiK<a, b, .., c>) » <b, -, c> 

Ta»l°<A> • A end T&*tyrt1to&m 

Occurs<A, B, i>»^»pi CWfW **£»»«» - i - 1>J 

Lastly, we say tupie A occurs at mdex I in tupm B if OrxursfA, B, i> hotds. 

.>v,;;:m > — *:■ ■■■' .« — -qe- ? " " : * : 

ill. Nulls ■ 

There is onty one, immutable object of typo amB, eonoted by af& 
equal: proctype(const null, mru) returns (beef) 

Always returns true. 
copy: proctype<const nog) return* (null) 

The obvious copy. 



M-'jf'*.-:; ;.«?;;. -??s™ 7,:'~'-v?K~. -y'-' >»%**»«*> 
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112. Boolean* 

There are two, immutable objects of type boot, denoted by tree and false They repreeent the 

logical truth values. 



and: procty pe<const bool, bool) returns (boel) 

proctypefeousf beef, bool) returns (bool) 



or: 



not: proctyp*(const bool) returns (bool) 

The standard toglcir>fonctlon«. 
equal: procty pe(conit bool, bool) return! (bool) 

Equal returns true Iff its arguments ere thessme. 
copy: proctypefcenst bool) returns (bool) 

Copy singly copies its argument. 

U.S. Integers 

Objects of the type int are immutable and represent • wjbr«nge of. the mathematical 
integers. The subrange (wNch may differ with each imp^ment^tan) is a clo««d interval 
[IntJ* n, Int_MexJ where Int_Mn * -2 15 +1 and Int JUax 2 2 1 *-!. An overflow exception la 

signalled by an Operation if the result would Me outside ^iaJajleavek v 

add: proctypefeonst Int, int) returns (int) signals (overflow) 

sub: proctype(const int, int) returns (fait) signals (overflow) 

pcoetype<wu*lnt,rnt)t*tmi«<ln0a^ 



mul 



The standard integer operations. ^ 

minus: procty pefeonst int) returns (int) signals (overflow) 

Minus returns the negative of Its argument. 

div: prbctypetconst int, int) returns (int) signals (zero jdrvtoe, overflow) 

Div computes the quotient of argl and arg2, U, the integer q such that 
(3r|0 sr< |arg2|) [argl - q * arg2 ♦ rj ZerOjdMde occurs if erg2 - 0. 
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power: proctypc<con»t tot, tot) rttnrns (int> stgnalt (nag sHve_pMpowent, overflow) 

This compute argl raised to the esg2 power. PoweHQ,0)« 1. ratgetive.exponent 
occurs tfarg2 <J0». . - -^ ■>.^-.— .'•■•■•■- 

mod: procty pe(cofl$t int, int) ret«rn* (tot) *% ii^$ (»roj*vW», ovw^tow) 

This computes the integer remainder of dWdmg aegj *!* irp2| !#., the resutt b 
»rgl - arg2*dtv(argl, erg2). Zero jdivide occurs » or % 

f rom.to Jby : itertypeCcentt tot, tot, tot) yteM* (canst t*m afcnaJs <»ro_atep) 

This iterator yields, m succession, argl, argl ; t jt&^p^^*,;*^^^ until the next 
value to be yielded, x, satisfies fr > arg2 A erg$ > 0) v (x < erg2 A erg3 < 0). 
Zero jstep occurs if argg **0. 

It: proctyp^const int, int) rrteros (beet) 

»e: proctypefcofttt in*, tot) reteras (beef ) 

equal: proctypeiconst tot, tot) reterfts (boot) 

go: proctjrpe(const tot, tot) reterns (beet) 

gt: procty poteenst tot, toOretorp* (beet) 

-Iff. ■:• t^fKtf.?****^'!^!* 1 ^:- 
copy: procty p<Kcontt tot) return* (tot) 

The obvious copy o p erati o n . 

II.4. Characters ' :: -° ■''■•■■■';■■■■'"■■> 7 

The objects of Jypo oOfcfr are 4tw nut seb , end r ap r a ierd characters. Every 
implementation is assumed to provide at least 128 characters, but no mere then 512. Character 
ere numbered from to some CWjop, and the i itim be rl m j d ofka j a the ordering for the eberecter 
type. The first' 128 characters are the ASCH chsrec ter s m their s tan da rd order. 

(2c: proctyp^censt tnt) returns <char) stfnals (Wa«a»_chsr) 

12c returns the character numbered argl m ths numb e r i ng of characters. IHegel_ch«r 
occurs iff the argument is not brthe range (0, Char .Top} 
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c2i: proctype(const char) return* (int) 

Returns the number corresponding to its argument. 

It: proctype<con*t char, char) retarns (bool) 

le: proctype<const char, char) returns (boo)) 

equal: p roc type(con»t char, ehar) ret«f»i« (booi) 

ge: proctypetconst char, char) returns (tool) 

gt: proctype<con»t char, char) returns (boot) 

The ordering relations consislenf with the numbering of chsrscters. 
copy: proctypefconst char) returns (char) 

The obvious copy. 
II.5. Strings . ; 

Strings are immutable objects. Each string represents a tuple of characters. The I th 
character of the string is. the i* h qsmpor*nt c* the tuple. The Saee* a string must be a tegel 
integer; if it is not, then a failure exception is signalled. Furthermore, a variable declared 
strine;[tti>mutt be able to store strings whose tfee doe* not exceed n, and may possibly store 

larger strings. 

size: proctype<con<t string) returns (Int) 

Returns tbe>siie Of the tuple representing Its argument. 

indexs: proctypefconst string, string) returns (int) 

The operation returns the least index at which arg2 occurs in argl. (Notice thet this 
me.™ 1 fe rrfurr^ If afgl is tba O-tupie.) If afg2 does not occur in argl, then is 
• ■■ ' returned.'. ■-■ '*■.*?■■ ■,■ 

indexc: proctypefconst string, char) returns (Int) 

Indexc returns the least index at which the 1 -tuple <erg2> occurs in argl. If <erg2> 
does not occur in argl, then is rehlrned. 

c2s: proctype(const char) returns (string) 
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Returns the string represented by the 1 -tuple <argl>. 
concat: proctypriconst siring , string) return* (string ) 

Concat returns the string for which «rgl || srg2 is the representation, 
append: proctype(ctmst string, chsr) returi 4m) 

This operation returns the string i spi ssotMeU bysrgl *f «org2>. 
fetch: proctype(const string, int) returns (cs^sigjjas* (hounoi) v 



Fetch returns the sr»2 th cbsracter of «?gL Beuees eocmrs If (erg2 < 1) v 
(arg2 > sizeCargl)). 

substr: prootypefeonst string, kit, int) return* Utrty) cignaJ* <bc*nds, negative.tize) 

Substr returns the string represented by the tuple of size 
min(arg3, siieiargl) - arg2 ♦ 1) which occurs at index arg2 in ergl. Bounds occurs if 
(arg2 < 1) v (arg2 > ritefjrgl} ♦ 1). NBg»ttve_si» occurs if arg3 < 0. 



■•ito 



rest: prociyp4oen»t string, int* 1 

Equivalent to substriargl, argg, tev$0t&%l^^m^i*J*lF& r kmtll 

•Sect proctype(con»t string) return* (arr«jr[ch«r]) 

This operation creates a new array, the a lam s wU of which ere the characters of the 
argument. The low. bound of the array is 1 4 snd theaUM of the^ray lsel>e(argl). The 
i th element of the trrty is the i& character of the string. 

ac2s: proctype<c*n«t arrayf cber}) return* (string) 

Ac2s is the inverse of s2ec The result J« the. sjring with; che^^ seme order 

as in its argument, Thus the i tn character of the resort is the «* tew<argl) - l)* h 
element of the argument. 

chars: itertype (const string) yields (const char) 

This iterator yields, in order, each character of Us ergumant. 



- IT'-. - 



It: 
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proctypetconst string, string) return* (hoop 
ie: proctype{const string, •trittf ) returns (boot) 



iMsfO-jj ' 



equal: proc*ype(censt tiring, string) returns (boot) 
ge: proctypeXconst string, string) retojiw (bool) 

gt: proetype(conft »trlng, »tH ■«• (booJ) 

These usa the usual l«)ricotr«p^ ordw4ngb«»d Oft th» Or<*wing for characters. Th« It 
operation is equivalent to the following procedures 

It - proefconst x, y: string) returns Mas: boel); 
c^ f filSej^lye^^ 
var mfh: fht; 
if stxe_x <» sIhlj 
then min :- size jc; 
else roin :- tiie_y; 
end if; 
for const i: int in tnt$fromjoJ>y ft, mtn, 1) do 
ifxm<yfi] 

then test :- true; return; 
end if; 
■ ■■ end for; . 
less :« (siiejc < slze_y); 
end It; 

copy: : proctypefeonst string) returns (string) 

The obvious copy. 
II-6; Arrays 

The array type generator defines an infinite class of rypes. For every type T there is a 
type ait ay[Tl Array objects are mutable. The state of an erre^obfcjct consists of J 

1. an integer Low, celled the low bound, and 

2a tuple EHs of objects of type T, ceded the elements. 



We also.dafine Si*e • SizetBts); ami Mfh > Lew + See - r/ : l^' want to tMnk of the components 
of Elt* a. being numbered from Lew, so watmfina the array Jr«fcw Of" the I th component to be 
(i - Low + 1). Each array object is of bounded sine, in two wave. Firet, It* Sfce, Low, and rtgh 
must all be legal integers. Secondly, Low and Ugh are bounded by the site of the variable 
containing the array object. Any attempts to vWate these rwtrfctions result in • failure 
exception: f ailureHllegal. J arrey^ihnfce first case, and taluVs^*variable overflow'*) fri the other. A 
variable (or object component) of type MTayfJi I, h) must be able to contain array objects with 
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Low «» I and High 5 h; it may be ante to contain larger arrays. If an array » a«signed to a variable, 
grown with addh or addl, or shitted with setjow, such that the Hmtts of the vartobte would be 
exceeded, then failureCVartefrte overflow") is ttgnattod, as m s rrtto rm d obove. 

For an array A, we »houid write t elc, to refer to the stele of that object, but 
subscripts will he dropped where the association is dear. 

Note that for all array operations, tf an exception occurs, (other than tenure), then the 
states of 1he arguments ere unchsmed f rom thi Hon. 

We use the abbraviaUon AT for tha type atttf fTi. 

create: proctype<const int) murns (AT) 

This returns »n array for wt^ch Low k erg 1 and ©t« is t> pie. 

new: proctypeO returns (AT) 

Equivalent to created). 

low: proctypeXcenst AT) returns (Jut) 

high: pratypetcenst AT) returns (tot) 
size: proctypetconst AT) returns (tot) 

These operations retotn Low, HhjK and Site, raspactryeh/. 

seijow: proctype(var AT, const int) 

Set Jow makes Low equal to arg2. This operation may mvohre physicstty *Nf4mg the 
elements of the array in storage, However, Stock Htove merrtttmm eveHabJe on many 
mschmeseanbe used to ha^> implement sat Jaw. 

trim: proctypefrar AT, const int, tot) signal* (bounds, ttegaHvayriie) 



This operation makes Low equal to erg2, and m ni to the tuple of sice 

min(arg3, High' - erg2 ♦ 1) which occurs in Bts' at index arg2 - Low' 4 1.1 That is, every 
element with •rra.yjndex tettrltarytfl^^ 

remoMod Bounds occur» if (arg2 < Low!) v (ssg2 >^igh' ♦ t). atounthJOjstee "occurs if 
• r g3 <Q. 



1. Etts\ Low', etc., refer to the stst. prior to invoking Uw operation, 
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fill: 



proctypeXconst int, lot, T) return* (AT) tig Mb (nogatlvejtoeJ 
where T has copy: proctypeteswst T) reterns (T) 



S-j-Hfl*"- 



F1M returns en array for which Low it aril, and Elts ia a (nwdO, arg2)Muple in which 
•very component U a copy? of ar#« « ceftt Tfcopy tnextt, erg2) times to got tho 
•»»manhi,lnof«»r. N^lvajrtr*.«ccur«if*rg2<a. *'••/•■•-• 

fetch: seltypettnt) of T from AT »J f nab (bound*) 



*<?.. 



Fetch selects the element of argl with array JndoK arg2. Bound* occura if 
(»r g 2<Low)v(»ri2>Hgh). 

bo,, °?? ! ^IW 1 ^ T .' *° w A |:% n«J* (bound.) 
to P ! *ltj?«>^ 

These operations aaloct tha alements wlfo srreyjndex's Low end Mgh, respectively. 
Bounds occurs if Size - 0. 



store: 



addh: 



proctype<Tar AT, const Int, T) slgnab (bounds) 

whew T has copy: pro ctyp s teomt T) reterns (T) 

Store makes Elts a new tuple which differ* from the ©H in that erg3 ia the element wrfh 
•weyjnde* arg2. Ifcopy; is used -*e copy the «gument. Bounds occura if 
(arg2 < tewl v (aff2 > ftghX 

proctypc(var AT, const T) 

where T has copy: prectype(eeftat T) reterns <T) 

This operation makes Ota the new tuple Efts* ♦ <erg2>. Tfcopy Is used to create the 
new component .■-*".■ • 

proctype(ver AT, const T) 

where T has copy: proctype<con«t T) returns (T) 

This operation makes Low equal to Low* - 1, end Elts the tuple <»rg2> * Elts'. Ttcopy is 
used to create the new component. ( P e trom m rttnt; ta» heepe the array Jnoax's of the 
previous eiem a n ts the same.) ' y ■*-' 



remh: proctypetvar AT) returns <T) signal) [(bounds) 



addi: 



,j f#f 






II *w»3© «h*»yQ8 Syw w*<^»"W* rt ^ *i* ** te*«*ift <*«# -#3al#* ffc?#1 



















iW* 



rf?r«4# r,I *,><««! '•<{«»•»* ,<HN#J • •» #1© feHl. s s ?» ** vaU'J&W* <*#.«#**•** i**'.#«**l*'» »«^. 



febrtuoA «**«$* T A «*%¥ T to C^se*^^**** ^^ 





rStdfe 




l#»* 




■MA 



fT: >.*w*wt '"'' MrtwrtHttyi*^ &ptm **^ ** xp*' 










s*fftrt*i 



zmp'^ ; ~3J~~ ?m -i^sgi^W^^' ~ ' 
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permuted.) Records are mutable objects. The state of a record of type rtcord[ldj: Tj, ~, Id n : T n ] 
is an n-topto. The i th tompo t w r^ of t^e tupte is Of type T[. Tn> f^ component is also called the 
Wptompoaeiit. W»*bk*9*Uto t t wl^ te^i !{, ^Ifyl J *f*T bihm. 

create: ; . fffje&jr^tegfttT^ -v* a .«-.-. - /■ f ? Vi " ; .:,■ . 

This operation returns a new record with the tuple <ergl, _, argN> at its state. It uses 
Tjlcopy to copy art,. Create is not aveileWe k*^ user, but «• use la imcOicit in the 
record constructor. „,.,-. .../- Ws ■■,.,, . , ; . &jN j « v ^-v 

I«%: ir aeltjpep o£T| fromRT ., 

this operation selects tha Id ( -component of its argument. There is an ld| operation for 
each Idj. ' *\j y . ; ; ,r- X ;.-j* . i_ ,\.,-. 

Putjdj: proctjrpe(var RT, con»t T,) .^, ; i -, iif :.- 

. where T, hu copy: proctjntfrnmt T t ) return* (ty ;,,.',,,. 



This operation makes the stale «£?$*} • ■|#p.^ge^a>fccb;: dW fares irpm the old, in thet 
its Idj-component is a copy of arg2 made using T,leopy. Thire is a put Jd) operation 
■ for each id). • '■'■" Y * : "' -'■' -^' ;:41 ? " J - '■■ ; ' : "'"" ' "' *' 

equal: proctypefcomt RT, RT) return* (boot) ,&» , 

where each T| baa equal: prociypeXconst T ( , Tj) returns (boot) 

This operation wmparat tt^ JucJat of arf^irKi ert^ aei necn snt by component using 
T,Sequa| tor the Idj-component. If aK the comparisons return return true, the result is 
;*ruUj otherwiee rlier»#utt*#ft^^ v, ' C: - ;1;{ '^•' 1ri '^** 

copy: proctype(const RT) returns (RT) 

where each T, baa copy: pro ctyp er cohit T|) retenn ftf) 

. TNs operation returns s record whose state is a copy of the state of the argument. 
This copy is wada flemg T^tcdpy for the I dfcom frtto rtt . 
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11.8. Oneofs 



The aueoftype generator defines an infinite ctese ©I types. For every tuple of id/type 
pairs <(Id 1( Tp, „., (Id^T^, where «H the id's »r* dWtett «oAM4wdcOtr#prfc is a 

type oneof[Id i: Tj, „., Id n : T n J (The user may write this type with the pairs permuted) Oneof 
objects are immutable. Each oneof object, is represent** by wpefHt^tk where X is Of type Tj. 
The idj part of the peif ts cefted tha iag^enrf^ V' : cei#Hne value. We abbreviate 
onroffldj: Tj, „., !d n : T n ] to OT below. 

mBkejdjrprectyp^conrtT^frtermfOT) 

wh«r« Tj has copy: piectyeetconst T,) retwrtW'rrjr 

This operation returns the oneof object for the peMty, ergl), using Tjlcopy. There is 
a make_Id| oparation for each Idj. 

»s_Idj: proct ype(const OT) return* (bool) 

This operation returns tree iff the tag of ergl it Idj. Its use is implicit in the tegcese 
statement. There is en isjd, Operation for eech .Idj. 

vehiejdpseityp^)^ 

If the argument has tag Idj, this selects the value pert oMbe argument. Wrong Jag 
occurs if the tag is not Idj. This operation is used JmpHcWy by the tefcese statement. 
There is a vaiuejdj for eech Id } . ! -i"^>".--r- '\ r \ :'* ■•.f'«5--\v ■-,- ■ •? 

equal: proctypefeonst OT, OT) returns (beet) 

whweechTihMequsitpiWyp^constTi.Tpreturaiajool) 

If the tags of the arguments are different, than faJse « returned. If the tags ere both 
Idj, then the result is Tjtequai applied to the value parts of the arguments. 

copy: proctrpe(coDStQT)fetBMaiOT) 

where each T, has copy: pioctypetceiHt Tj) reterns (T,) 

This operations returns a oneof object wgfc the seme teg M it* argument, end e value 
part a copy of the vahm pert of the argument. If the teg is Id,, then the copy is made 
using Tjlcopy. 
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1 1 J. Pointers 

The pointer type generator defines an infinite clacs of types. For each area A, and each 
type T, ptr[A, T] is a type. The represented of pointers is riot defined explicitly, but implicitly 
through the behavior of pointer objects. Pointer objects ere immutable. We abbreviate ptrfA, T) 
to FT below. '•■ ' * 

nilptr: proctypeO returns (PT) 

This operation return* a pointer th»t painU t*no ofa#et Therefore, « is equal only to 
other null pointers of the same type, and «nnpt be der.ter.nced. 

alloc: proctypefconst T) returns (PT) signals (famjretoriftg)) 

where T has copy: proctype<con»t T) returns (T) 

This operation creates a copy of argl In area A, returning a pointer to the newly 
created object. The copy is made using Ttcopy. FaHur. occurs if the are. cannot 
contain the new objects the string signalled is "area out of memory". 

deref : seltypcO of T from PT signals (bad j»o»nter) 

This operation "follows" a pointer to the object pointed at. Bed_pointer occurs if the 
null pointer is dereferenced. 

equal: prectypefeonst PT, PT) returns (booi) 

This operation returns false unless argl and arg2 point to the same object, or argl and 
arg2 are both null pointers. 

copy: proctype(con$t PT) returns <PT) 

i 
This operation returns a pointer equal to its argument. That is, the result points to th. 
same object as the argument. 

IMO. Areas 



An area object is used for the dynamic allocation of other objects, 
new: proctypeCconst string, int) returns (are.) signal* (bed_arguments) 
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This operation returns .new area. Argl it used to, describe what sort of area 
management scheme is desired, and «rg2 is for size* The maiiilim of both arguments is 
implementation dep en d e nt. 

It.il. Procedures, Iterators, a«d Selector* 

Fo¥ each procedure, iterator, and selector typo there are WtraaiLO|»wieHoi^cwd% f copy t 
and equal. Create is not available to the user; its use it imp** '-** the compiler and run-time 
system. Copy presumably does not copy the object coda * • msi»»; be* mere*y a descriptor. 
Equai does not mean "computationally equivalent". Two rwirirme dertved from the same module 
with the samp parameters (If any ) are ce nsl d a. ed a q ua H ^t^m^Mtmmi^m^'t^t^^m of a 
"'"** nrtrfnrait tn lie iWifineiit Piwuluiei 
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